CD 5221

ESCUELA POLITCNICA NACIONAL
FACULTAD DE INGENIERIA DE SISTEMAS

DESARROLLO DE UNA APLICACIN MVIL PARA RECUENTO
DE STOCKS E INVENTARIOS TRANSFERIDO MEDIANTE WEB
SERVICES.

PROYECTO PREVIO A LA OBTENCION DEL TITULO DE INGENIERO EN
SISTEMAS INFORMATICOS Y DE COMPUTACION

ORTIZ TAMAYO IRWIN GABRIEL
Irwing844@hotmail.com

DIRECTOR: Ing. Csar Esquetini Cceres
cesqueti@innovateq.net

Quito, Agosto 2013
2

DECLARACIN

Yo, Irwin Gabriel Ortiz Tamayo, declaro bajo juramento que el trabajo aqu
descrito es de mi autora; que no ha sido previamente presentado para ningn
grado o calificacin personal; y, que he consultado las referencias bibliogrficas
que se incluyen en este documento.

A travs de la presente declaracin cedo mis derechos de propiedad intelectual
correspondiente a este trabajo; a la Escuela Politcnica Nacional, segn lo
establecido por la Ley de Propiedad Intelectual, por su Reglamento y por la
normativa institucional vigente.

__________________________
Irwin Gabriel Ortiz Tamayo

3

CERTIFICACIN

Certifico que el presente trabajo fue desarrollado por Irwin Gabriel Ortiz Tamayo,
bajo mi supervisin.

_______________________
Ing. Csar Esquetini Cceres
DIRECTOR DEL PROYECTO
4

AGRADECIMIENTO

A lo largo del camino te encuentras con personas que marcan tu vida. Cuando
volteas a ver el camino que has recorrido agradeces por las vidas de las personas
que influyeron en dicho camino.
Existen personas apasionadas por la excelencia como mi Madre, gracias por
hacer de m una mejor persona a travs de tus consejos, enseanza y amor.
A mi Padre, apasionado por la sabidura, gracias por brindarme los recursos
necesarios y estar a mi lado apoyndome y aconsejndome siempre.
Si alguien siente pasin por el valor y el coraje es mi hermano, gracias por estar
presente, ser un apoyo, ser un amigo ms que un hermano.
A mi compaera, amiga, novia, esposa;gracias por su nimo y fuerza.Su pasin
por el arte y la psicologa es inmensa.Compartimos pasin por los perdidos, por
ello estoy agradecido tambin.
Pero la mayor de todas las pasiones, la tiene Dios. Su pasin por el hombre es
inmensurable, indiscutible e interpretable. A l le agradezco por su pasin por m.
Yo har de l mi pasin tambin,

Irwin Ortiz

5

DEDICATORIA

Dedico este trabajo a todos los pensadores, filsofos, cientficos y soadores en
general. Que desean no solo crear ciencia, sino hacerla productiva para la
sociedad. A ellos que no se autoimponen lmite, que desestiman la razn incluso,
que suean por crear, a ellos mi trabajo.

Irwin Ortiz

6

INDICE GENERAL

INTRODUCCIN ........................................................................................................................... 13
CAPTULO I .................................................................................................................................... 15
1 PLANTEAMIENTO DEL PROBLEMA ................................................................................. 15
1.1 Descripcin del problema ..........................................................................................................15
1.2 Objetivos del proyecto ...............................................................................................................16
1.2.1 Objetivo General ...................................................................................................... 16
1.2.2 Objetivos Especficos ............................................................................................... 16
1.3 Alcance del Proyecto .................................................................................................................17
1.3.1 Limitaciones ............................................................................................................. 18
1.3.2 Proyeccin Social ..................................................................................................... 18
1.4 Anlisis y Estructura de los Inventarios ....................................................................................19
1.4.1 Concepto de Inventarios ........................................................................................... 19
CAPTULO II .................................................................................................................................. 20
2 ASPECTOS METODOLGICOS .......................................................................................... 20
2.1 Metodologas de Desarrollo ......................................................................................................21
2.1.1 Metodologas agiles para desarrollo de software mvil .......................................... 22
2.1.1.1 Desarrollo gil! "rograma#i$ %&trema '(") ........................................................ 24
2.1.1.2 Desarrollo gil! *#r+m .......................................................................................... 26
2.1.1.3 Mo,ile-D ............................................................................................................... 28
2.1.2 .ara#tersti#as / re0+erimie$tos espe#fi#os del e$tor$o mvil ............................. 30
2.2 Arquitecturas .............................................................................................................................33
2.2.1 *12 ........................................................................................................................... 33
2.2.2 3"M .......................................................................................................................... 34
2.2.3 4e$ta5as 0+e aporta 3"M a *12 .............................................................................. 34
2.2.4 4e$ta5as 0+e aporta *12 a 3"M .............................................................................. 35
2.3 Seleccin de Metodologa .........................................................................................................35
2.3.1 Motiva#i$................................................................................................................ 35
2.3.2 "ri$#ipios ,si#os Metodologa Mo,ile-D ................................................................ 36
2.3.2.1 6ase de %&plora#i$ .............................................................................................. 37
2.3.2.2 6ase de 7$i#iali8a#i$ ............................................................................................ 38
2.3.2.3 6ase de 9"rod+#ti8a#i$9 ..................................................................................... 39
7

2.3.2.4 6ase de %sta,ili8a#i$ ........................................................................................... 39
2.3.2.5 6ase de "r+e,as.................................................................................................... 40
2.3.3 %$fo0+e pragmti#o ................................................................................................. 40
2.4 Seleccin de herramientas de desarrollo ...................................................................................41
2.4.1 *ervi#ios :e, ........................................................................................................... 41
2.4.2 2pli#a#i$ Mvil ;ativa ............................................................................................ 43
2.4.2.1 2pre$di8a5e .......................................................................................................... 44
2.4.2.2 <eleva$te .............................................................................................................. 44
2.4.2.3 .digo 2,ierto...................................................................................................... 45
2.4.3 7$trod+##i$ a la plataforma 2$droid ...................................................................... 45
2.4.3.1 2r0+ite#t+ra 2$droid ........................................................................................... 46
2.4.3.2 Desarrollo e$ la plataforma 2$droid .................................................................... 48
2.4.3.3 %$tor$o de Desarrollo .......................................................................................... 49
2.5 Seleccin de herramientas de almacenamientos de datos..........................................................51
CAPTULO III ................................................................................................................................. 53
3 MODELAMIENTO DEL SISTEMA ...................................................................................... 53
3.1 Modelamiento del negocio ........................................................................................................54
3.1.1 4isi$ =e$eral del *istema ....................................................................................... 54
3.1.2 %sta,le#imie$to de las partes i$teresadas '*ta>e?older %sta,lis?me$t) ................ 54
3.1.2.1 @efe de "ro/e#to ................................................................................................... 54
3.2 Modelamiento de requerimientos del sistema ...........................................................................54
3.2.1 Defi$i#i$ de re0+erimie$tos i$i#iales '7$itial <e0+ireme$ts .olle#tio$) ................ 55
3.2.1.1 <e0+erimie$tos 6+$#io$ales ................................................................................ 55
3.2.1.2 <e0+erimie$tos ;o 6+$#io$ales .......................................................................... 57
3.2.2 Defi$i#i$ de la pla$ifi#a#i$ del pro/e#to '7$itial "ro5e#t "la$$i$g) ...................... 57
3.2.2.1 .ro$ograma del pro/e#to .................................................................................... 58
3.2.2.2 2$lisis de .ostos ................................................................................................. 59
3.2.2.3 <e#+rsos A+ma$os ............................................................................................... 60
3.3 Modelamiento del anlisis y diseo del sistema ........................................................................61
3.3.1 2$lisis del *istema .................................................................................................. 62
3.3.1.1 2$lisis de "ro#esos del sistema .......................................................................... 62
3.3.1.2 Bar5etas de Aistorias de Cs+ario '*tor/#ards) ...................................................... 69
3.3.1.3 Bareas por 7tera#i$ ............................................................................................. 77
8

3.3.1.4 Bar5etas de Bareas 'Bas>.ards) ............................................................................. 78
3.3.2 DiseDo del *istema ................................................................................................... 82
3.3.2.1 7$fraestr+#t+ra / 2r0+ite#t+ra del *istema .......................................................... 83
3.3.2.2 "rimera 7$tera##i$ .............................................................................................. 83
3.3.2.3 *eg+$da 7$tera##i$ ............................................................................................. 83
3.3.2.4 Ber#era 7$tera##i$ .............................................................................................. 84
3.3.2.5 .+arta 7$tera##i$ ................................................................................................ 84
3.3.2.6 E+i$ta 7$tera##i$ ................................................................................................ 84
3.3.2.7 *e&ta 7$tera##i$ .................................................................................................. 84
3.3.3 ;ome$#lat+ras ......................................................................................................... 85
3.3.3.1 ;om,re de %$tidades ........................................................................................... 85
3.3.4 Modelo de datos ...................................................................................................... 86
3.3.4.1 Modelo %$tidad F <ela#i$ .................................................................................. 87
3.3.4.2 Di##io$ario de Datos ............................................................................................ 88
CAPTULO IV ................................................................................................................................. 92
4 IMPLEMENTACIN Y PRUEBAS ....................................................................................... 92
4.1 Implementacin del sistema ......................................................................................................92
4.1.1 %st$dar de .odifi#a#i$ .......................................................................................... 92
4.1.1.1 .o$ve$#io$es ge$erales para #lases / mGtodos .................................................. 92
4.1.1.2 Defi$i#i$ de #lases / mGtodos ............................................................................ 92
4.1.1.3 Defi$i#i$ de #lases de a##eso a datos ................................................................ 93
4.1.1.4 Defi$i#i$ de #lases de $ego#io ........................................................................... 94
4.1.2 "la$ifi#a#i$ de pa$tallas ......................................................................................... 95
4.1.2.1 Diagrama de <ela#io$es de pa$talla .................................................................... 95
4.1.3 *eg+imie$to de itera#io$es ...................................................................................... 97
4.1.3.1 Da de "la$ea#i$ ................................................................................................. 97
4.1.3.2 Da de "rograma#i$ o Bra,a5o ............................................................................ 99
CAPTULO V ................................................................................................................................ 114
5 CONCLUSIONES Y RECOMENDACIONES ..................................................................... 114
5.1 Conclusiones ...........................................................................................................................114
5.1.1 Metodologa de Desarrollo ..................................................................................... 114
5.1.2 Aplicacin Mvil Para Recuento De Stocks E Inventarios .................................... 115
5.2 Recomendaciones ....................................................................................................................115
9

5.2.1 Metodologa de Desarrollo ..................................................................................... 115
5.2.2 Aplicacin Mvil Para Recuento De Stocks E Inventarios .................................... 116
BIBLIOGRAFIA ............................................................................................................................ 117
ANEXOS........................................................................................................................................ 120

10

INDICE DE TABLAS

Tabla1. .omparativa e$tre #ara#tersti#as del desarrollo gil / del desarrollo mvil ..................... 23
Tabla2. 2portes de diversas Metodologas 2giles a Mo,ile-D ........................................................ 36
Tabla3. Be#$ologias 2so#iadas 2 .;%B H @2%% .................................................................................. 42
Tabla4. 4e$ta5as o desve$ta5as e$tre .;%B / @2%% ........................................................................... 42
Tabla 5. .ostos por miem,ro del %0+ipo ......................................................................................... 59
Tabla 6. .ostos por dispositivos mviles ......................................................................................... 60
Tabla 7. .ostos por dispositivos mviles ......................................................................................... 60
Tabla 8. <oles / <espo$sa,ilidades .................................................................................................. 61
Tabla9. %st$dar de $ome$#lat+ra F Ba,las .................................................................................... 85
Tabla10. %st$dar de $ome$#lat+ra F 2tri,+tos ............................................................................. 85
Tabla 11. Iista de %$tidades ............................................................................................................. 88
Tabla 12. Di##io$ario %$tidad #ategoriaIi,ro .................................................................................. 88
Tabla 13. Di##io$ario %$tidad #ategoriarol ...................................................................................... 88
Tabla 14. Di##io$ario %$tidad #lie$te .............................................................................................. 89
Tabla 15. Di##io$ario %$tidad detallesto#> ...................................................................................... 89
Tabla 16. Di##io$ario %$tidad detalleve$ta ..................................................................................... 89
Tabla 17. Di##io$ario %$tidad li,ro .................................................................................................. 89
Tabla 18. Di##io$ario %$tidad me$sa5epeti#io$ ............................................................................... 89
Tabla 19. Di##io$ario %$tidad rol ..................................................................................................... 90
Tabla 20. Di##io$ario %$tidad sto#> ................................................................................................. 90
Tabla 21. Di##io$ario %$tidad s+#+rsal ............................................................................................ 90
Tabla 22. Di##io$ario %$tidad tra$sa##io$ ....................................................................................... 90
Tabla 23. Di##io$ario %$tidad +s+ario ............................................................................................. 90
Tabla 24. Di##io$ario %$tidad ve$ta ................................................................................................ 91
Tabla 25. <es+me$ de *tor/#ards "la$ifi#ados ............................................................................... 98
Tabla 26. <es+me$ de Bas>.ards "la$ifi#ados ................................................................................ 99
Tabla27. <es+ltado "r+e,a C$itaria Iogi$ de +s+arios ................................................................. 105
Tabla 28. .o$sidera#io$es de$tro de la %val+a#i$ =e$eral de la 2pli#a#i$ .............................. 110

INDICE DE FIGURAS

Figura1. 6ases de la metodologa para desarrollo mvil Mo,ile-D ................................................. 28
Figura2. .i#lo de desarrolloJ metodologa Mo,ile-D. ...................................................................... 37
Figura3. "o,la#i$ 0+e +sa #ierto tipo de te#$ologia ...................................................................... 45
Figura 4. Diagrama de ar0+ite#t+ra de la plataforma 2$droid. ....................................................... 48
11

Figura5. .apt+ra de pa$talla del 7D% %#lipse #rea$do +$ $+evo pro/e#to 2$droid ........................ 49
Figura6..apt+ra de pa$talla del %m+lador de 2$droid ................................................................... 50
Figura7. %s0+ema #omer#ial de *EI *%<4%< 2008 .......................................................................... 51
Figura8. %tapas de la fase de %&plora#i$ K22L ................................................................................ 53
Figura9. .ro$ograma del pro/e#to por etapas metodolgi#as. ...................................................... 58
Figura10. .ro$ograma de la etapa de prod+#ti8a#i$. .................................................................... 58
Figura11. .ro$ograma de la etapa de prod+#ti8a#i$ para el *tor/#ard MIogi$ de Cs+ariosN ....... 59
Figura12. "ro#eso 3"M para Iogi$ de +s+arios ............................................................................... 62
Figura13. "ro#eso 3"M para =esti$ de Cs+arios ........................................................................... 63
Figura14. "ro#eso 3"M para =esti$ de <oles ................................................................................ 63
Figura15. "ro#eso 3"M para gesti$ de 2gr+pa#i$ de Cs+arios ................................................... 64
Figura16. "ro#eso 3"M para <egistrar *to#> ................................................................................... 64
Figura 17. "ro#eso 3"M para <egistrar 4e$ta ................................................................................. 65
Figura 18. "ro#eso 3"M para <egistro Braslado .............................................................................. 65
Figura 19. "ro#eso 3"M para .o$s+lta de Ii,ro e$ otra *+#+rsal ................................................... 66
Figura 20. "ro#eso 3"M para =esti$ .ategora de li,ros .............................................................. 66
Figura 21. "ro#eso 3"M para =esti$ de *+#+rsales ....................................................................... 67
Figura 22. "ro#eso 3"M para =esti$ de <eportes ......................................................................... 67
Figura 23. "ro#eso 3"M para =e$era#i$ de <eportes ................................................................... 68
Figura 24. "ro#eso 3"M para %&portar a diversos formatos ........................................................... 68
Figura 25. "ro#eso 3"M para =e$era#i$ de =rfi#os %stadsti#os ................................................ 69
Figura 26. Bareas por 7tera#i$ / por 7terar ..................................................................................... 78
Figura 27. 7$fraestr+#t+ra Be#$olgi#a del *istema ......................................................................... 83
Figura 28. Modelo %$tidad - <ela#i$ .............................................................................................. 87
Figura 29. Diagrama de #lases de a##eso a datos. ........................................................................... 94
Figura30. Mapa de pa$tallas de la 2pp. Mvil ................................................................................ 96
Figura 31. :e, *ervi#e .ompro,ar2+te$ti#idadCs+ario:*......................................................... 100
Figura 32. .lase .ade$as*EI ......................................................................................................... 101
Figura 33. .lase .o$e&io$*EI ........................................................................................................ 102
Figura 34. 7$terfa8 de la 2pp Mvil de 7$i#io ................................................................................. 102
Figura 35. 7$terfa8 2pp MvilJ .aso 1 de "r+e,a C$itaria Iogi$ de Cs+ario ................................. 103
Figura 39. 7mpleme$ta#i$ MGtodo 2+te$tifi#arCs+ario') ........................................................... 106
Figura 40. 7mpleme$ta#i$ de la #a,e#era de la .lase @ava .o$e&io$*12". ................................ 106
Figura 41. "asos impleme$tados para armar peti#i$ *12" e$ .lase .o$e&io$*12" ................. 108
Figura 42. =rfi#o de re$dimie$to ."C / <%D ............................................................................... 111
Figura 43. Biempos de <esp+esta por +s+arios ............................................................................. 111
Figura 44. Biempos de resp+esta por 6+$#io$alidad ..................................................................... 112

12

INDICE DE STORYCARDS

Storycard 1. Iogi$ de +s+arios ......................................................................................................... 69
Storycard 2. =esti$ de +s+arios ..................................................................................................... 70
Storycard 3. =esti$ de roles ........................................................................................................... 70
Storycard 4. =esti$ de agr+pa#i$ de +s+arios ............................................................................. 71
Storycard 5. <egistrar sto#> a#t+al .................................................................................................. 71
Storycard 6. <egistrar ve$ta ............................................................................................................ 72
Storycard 7. <egistrar traslado ........................................................................................................ 72
Storycard 8. .o$s+ltar li,ro e&iste$te e$ otra s+#+rsal ................................................................... 73
Storycard 9. =esti$ de #ategoras de li,ros ................................................................................... 73
Storycard 10. =esti$ de s+#+rsales ................................................................................................ 74
Storycard 11. =esti$ de reportes ................................................................................................... 74
Storycard 12. =e$era#i$ de reportes............................................................................................. 75
Storycard 13. %&portar a diversos formatos .................................................................................... 75
Storycard 14. =e$era#i$ de grfi#os estadsti#os .......................................................................... 76
Storycard 15. *eg+ridad ................................................................................................................... 76

INDICE DE TASKCARDS

TASKCAR1. "o,lar 3ase de Datos #o$ parametri8a#i$ i$i#ial. ....................................................... 79
TASKCAR2. %la,ora#i$ de .lases e 7$terfa#es para Iogi$ de +s+arios e$ *ervidor .e$tral. .......... 79
TASKCAR3. %la,ora#i$ / "+,li#a#i$ de :e, *ervi#e's) para Iogi$ de Cs+arios. ......................... 80
TASKCAR4. DiseDo de 7$terfa8 de Cs+ario e$ 2pp Mvil para Iogi$ de Cs+arios. .......................... 80
TASKCAR5. %la,ora#i$ de .lases e 7$terfa#es para .o$s+mo de :e, *ervi#es para Iogi$ de
Cs+arios e$ dispositivo mvil........................................................................................................... 81
TASKCAR 6. <e0+erimie$tos ;o 6+$#io$ales para Iogi$ de Cs+arios. ............................................ 81
TASKCAR 7. .rea#i$ de 2pli#a#i$ :e, Iigera. ............................................................................. 82

13

INTRODUCCIN

Las tecnologas mviles son una de las tecnologas ms imponentes e
innovadoras que han reaparecido y que se han producido en la era post-PC. Es
ms, podramos decir que dicha era comienza con la aparicin de dispositivos
mviles, que posee caractersticas inteligentes. Mientras esta tecnologa
evolucione, se hace posible la implementacin de dispositivos ms avanzados y
con ellos, a ms de tener sistemas de informacin sofisticados, se aade una
caracterstica propia e intrnseca de los dispositivos mviles: portabilidad. Esto
otorga mayores capacidades a tareas de campo que exigen a trabajadores,
empleados, etc. manejar grandes cantidades de informacin mientras se
movilizan en su rea de trabajo o rea funcional, apartados de sus terminales de
escritorio.
El inventario se usa en la mayor parte de las actividades de produccin,
asistencia, comercializacin y ventas. Se puede decir incluso que un inventario es
la forma prctica en la que la actividad de un negocio puede ser estimada. El
inventario se puede definir como un recurso almacenado al que se recurre para
satisfacer una necesidad actual o futura[1].Por lo que se recalca la importancia
de conocer y administrar estos datos de forma clara.
Se puede decir tambin que este es un proceso que soporta o alimenta otros dos
procesos fundamentales: el suministro y la demanda. El proceso de suministro
aporta con bienes al stock para satisfacer el anlisis producto del inventario,
mientras que la demanda consume el stock que el mismo inventario asegur que
exista. El inventario como proceso es necesario debido a las diferencias en los
controles y los tiempos entre el suministro y la demanda.
El presente documento se basa en el desarrollo de un sistema de inventarios que,
a travs de un dispositivo mvil con conexin a Internet, actualiza los datos
almacenados en un servidor de tal manera que se aumenta la eficiencia en el
control de inventario.
14

Se presenta el anlisis, diseo y arquitectura con el fin de poner a disposicin
esta informacin al momento del desarrollo de aplicaciones mviles que se
comuniquen a travs de una conexin de datos con un servidor.
El proyecto consiste en desarrollar un sistema mvil para recuento de stocks e
inventarios en el que se implemente Web Services para la transferencia de
informacin, administrndolo bajo una aplicacin web la cual sus clientes pueden
ser ordenadores con una conexin a Internet, a efecto de maximizar el
automatismo de los recursos en las instituciones.
El sistema posee un mdulo para la gestin de seguridad, dicho modulo permite
crear diferentes roles y tipos de usuarios asignndoles incluso sus permisos de
acceso. Este tambin permite gestionar a su vez un log de las transacciones que
se realicen en el sistema.
El proyecto se implementar en un prototipo basado en los datos de la institucin
CODEU
1
. Dicha institucin preocupada por el mejoramiento de la educacin,
desde 1995, en convenio con el Center for Teaching Excelence de la Universidad
de Maryland, imparte capacitacin sobre tcnicas didcticas y pedaggicas para
el mejoramiento del proceso de enseanza y aprendizaje
2
.
El presente documento est dividido en cinco captulos: el primero,
Planteamiento del Problema, se enfoca en detallar el problema del cual se parte
para plantear una solucin. El segundo captulo, Aspectos Metodolgicos, en el
que se realiza la seleccin de la metodologa y la descripcin de las herramientas
con las cuales se va a trabajar durante el desarrollo del proyecto.
El tercer captulo, Modelamiento del Sistema, contiene la especificacin de los
requerimientos, el respectivo anlisis y diseo de la arquitectura que ser
implementada de acuerdo a la metodologa utilizada. El cuarto captulo,
Implementacin, Pruebas y Evaluacin del Sistema, detalla el proceso de
implementacin del sistema, las pruebas realizadas y la evaluacin del sistema
obtenido. Por ltimo, el quinto captulo Conclusiones y Recomendaciones, lista
las conclusiones y recomendaciones del Proyecto.

1
.orpora#i$ para el Desarrollo de la %d+#a#i$ C$iversitaria
2
%&tra#to de ?ttp!OOwww.#ode+.org.e#Oa#er#ade.?tml
15

CAPTULO I

1 PLANTEAMIENTO DEL PROBLEMA

Los inventarios al ser un mtodo y un documento de sondeo situacional, son parte
vital de las empresas comerciales, productoras e incluso proveedoras de
servicios. Es preciso y necesario para estas empresas tener un control eficiente
de productos, proveedores, categoras, bodegas, entradas, salidas, traslados, etc.
a efecto de incrementar el automatismo de los recursos y la gestin en las
instituciones.

1.1 Descripcin del problema

Generalmente, la informacin de ciertos sistemas de inventario que existen en la
actualidad no es operativa en tiempo real, es decir, no se encuentra actualizada,
esto se debe a que la mayora de empresas realizan el control del stock de forma
manual. Esto produce muchas veces, inconsistencia al momento de manejar
mucha informacin o simplemente el mecanismo de inventario arroja valores que
se deterioran rpidamente y esto hace que el anlisis de dicha informacin sirva
muy poco para la correcta toma de decisiones. Por ello, como resultado de este
proceso, no se estimandatos certeros de un stock exacto y real.
El proyecto Desarrollo de una Aplicacin mvil para recuento de stocks e
inventarios analizando la informacin trasferida mediante Web Services,
contribuir a la modernizacin y automatizacin de la toma de inventario de
cualquier empresa que maneje un stock de productos. De esta manera el
personal encargado de suministrar el conteo del stock lo podr hacer
inmediatamente, a travs de un dispositivo mvil con conexin de datos hacia
Internet. Esto, desde cualquier lugar en el que este stock se encuentre y
transmitiendo esta informacin inmediatamente hacia el servidor destino;
16

ahorrando tiempo, recursos y generando un proceso automtico de carga de
datos. Ademsse proporciona informacin oportuna, veraz y actualizada.
La administracin del sistema est definida por medio de una aplicacin web, por
medio de la que se estimar y se dispondrn bodegas, catlogos de productos,
unidades de medida, categoras, niveles mximos y mnimos de producto en
inventario, stocks, usuarios, etc. Asimismo, se dispondr de reportes con grficos,
con la posibilidad de exportarlos a hojas de clculo de MS Excel. Esto en tiempo
real y arrojar el proceso de inventario tomado con dispositivos mviles. Adems,
la administracin de dichos reportes podrn ser consultados en lnea.
La sistematizacin automtica del proceso de conteo de stocks brindar
informacin oportuna, consistente y confiable de manera fcil y rpida, reduciendo
de esta manera los recursos y egresos que cada empresa asigna para esta tarea.

1.2 Objetivos del proyecto

1.2.1 Objetivo General

Desarrollar un sistema mvil para recuento de stocks e inventarios en el
que se implemente Web Services para la transferencia de informacin,
administrndolo bajo una aplicacin web, a efecto de maximizar el
automatismo de los recursos en las empresas.

1.2.2 Objetivos Especficos

Crear una aplicacin para el recuento de stocks e inventarios, que funcione
en un dispositivo mvil.
Establecer comunicacin entre el dispositivo mvil y el servidor de base de
datos por medio de una red inalmbrica usando Internet con tecnologa
Web Services, para la actualizacin instantnea de registros.
Elaborar simultneamente una aplicacin web que permita el acceso y
17

anlisis automtico de la informacin.
Desarrollar juntamente con la interfaz Web un mdulo de reportes fciles
de adaptar a cualquier proceso organizacional dentro de la empresa.
Desarrollar una interfaz Web para que los usuarios del sistema puedan
tener acceso al sistema a travs de Internet desde cualquier lugar.

1.3 Alcance del Proyecto

Para lograr un planteamiento claro de las reas que abarca el proyecto de
desarrollo y para definir con mayor detalle y precisin las diferentes capacidades
que conformarn su funcionalidad, se han identificado los aspectos que sern
tomados en cuenta en el diseo y desarrollo del mismo.

A continuacin, se presenta un listado de dichos aspectos, con el cual se
describen los alcances del proyecto de desarrollo.

El desarrollo constar de:

Una aplicacin mvil donde el usuario podr hacer el recuento del stock o
del inventario y enviar en tiempo real dicha informacin hacia un servidor
central.
El sistema contar con la administracin de catlogos de productos,
proveedores, unidades de medida, categoras, bodegas.
Mdulo de seguridad para el manejo y control de acceso de diferentes
niveles de usuarios.
Mdulos de entrada de productos, salida y traslados para que puedan ser
administrados y usados para el recuento de stock.
Por medio de la interfaz de administracin web, a travs de la Internet, ser
posible generar reportes impresos y exportar, si es que el usuario lo desea,
a hojas de clculo de MS Excel, adems de realizar consultas de
productos, traslados, proveedores y requisiciones.
18

El sistema ser capaz de mantener un registro (log) de todas las
transacciones, especificando quien la realiz y cuando.

1.3.1 Limitaciones

El sistema no ser implementado en un ambiente real. Se implementar un
prototipo de forma de prueba de concepto[2].
El sistema no contar con un proceso para migrar datos, sino que la
organizacin que quiera implementarlo tendr que adaptarse a los
parmetros descritos.
El sistema estar diseado nicamente para inventario de un stock de
productos, no de servicios.

1.3.2 Proyeccin Social

Mediante el desarrollo e implementacin del prototipo del proyecto se estima la
posibilidad de auto inducir hacia un concepto de automatizacin de procesos
convencional que se los realiza de manera manual.

El sistema web de administracin y de reportera permitir a las organizaciones
ahorrar tiempo, recursos y estimar de mejor manera la productividad. Siendo una
ventaja de la tecnologa al prestar servicios, la mejora de los procesos sin una
inversin significativa y costosa como otro tipo de tecnologas.

Asimismo, obtener el inters de estudiantes y desarrolladores para utilizar y
aprender acerca de esta tendencia que en nuestro pas se encuentra en un
estado prematuro todava. Adems, permitir generar el inters de empresarios
para mejorar sus servicios haciendo uso de muchas de sus ventajas como la
portabilidad, y el hecho de ser una tecnologa relativamente barata.

19

1.4 Anlisis y Estructura de los Inventarios

1.4.1 Concepto de Inventarios

Un inventario es una cantidad almacenada de materiales que se utiliza para
facilitar la produccin o para satisfacer las demandas del consumidor.
Normalmente, los inventarios incluyen materia prima, productos en proceso y
productos terminados [3]. Siguiendo con esta definicin se podra decir que este
proceso contempla bienes tangibles para la produccin de bienes o produccin de
servicios y su posterior comercializacin.
Adems, en el concepto de inventario se involucra las partidas del activo corriente
que se encuentran predispuestas en un stock, es decir, listas para su
comercializacin, y dentro de esta percepcin las partidas de activo corriente se
tendr en cuenta como todos los artculos que posee una empresa u
organizacin, en un almacn o bodega, estimada a costo de adquisicin. En una
empresa que comercializa su stock, el inventario toma el valor de sus artculos
destinados para la venta.
Para el caso del prototipo a desarrollarse en la presente investigacin, se har
referencia nicamente a inventarios de productos terminados.
Los inventarios de productos terminados incluyen elementos transferidos por el
proveedor directamente a su distribucin. Y el proceso de toma fsica de
inventario se encuentra alojado en las tiendas o puntos de distribucin que tenga
el producto terminado, es decir, aquellos que an no han sido vendidos. El nivel
de inventario de productos terminados depender directamente de las ventas, o
sea, su nivel est dado por la demanda.

20

CAPTULO II

2 ASPECTOS METODOLGICOS

El negocio de las aplicaciones mviles da tras da se encuentra en un proceso de
cambio y desarrollo constante. Con ello crece su demanda, volvindose ms
rentable, de la manera que se hace con el software convencional
3
. Se hace
hincapi en la forma de optimizar los recursos con los que el desarrollador llevar
al xito el proceso de desarrollo. Una forma de optimizar los recursos es contando
con una metodologa que conduzca al desarrollo oportuno, eficaz y eficiente de
aplicaciones. Sin olvidar, la relacin de estas con su entorno y caractersticas
propias de las aplicaciones mviles. De esta manera, se tratara de mitigar el uso
inadecuado de metodologas tradicionales por parte del desarrollador de
aplicaciones mviles. A pesar de que los desarrolladores conocen que el software
mvil debe satisfacer requerimientos y restricciones especiales, utilizan
metodologas tradicionales que resultan ser incompatibles con este tipo de
tecnologa.

El proceso de desarrollo de aplicaciones mviles afronta tambin la segmentacin
del mercado y demanda de estas en una variada gama de plataformas
incompatibles, varias de estas son: Symbian, Windows Phone, iPhone SDK,
Android o Java, entre otras. Todo esto hace que el proceso de desarrollo para
plataformas mviles sea ms complejo.

En las prximas secciones se adecuar el tema para la seleccin de la
metodologa gil de desarrollo de software mvil. Para ello, primero se abordar
brevemente el tema de las metodologas giles, y despus se explicar las
caractersticas propias y problemas a la hora de tratar dispositivos mviles con
sus respectivos entornos.

3
20+ el tGrmi$o #o$ve$#io$al ?a#e refere$#ia al software desarrollado para termi$ales fi5as.
21

Despus, se comenta brevemente dos metodologas giles generales y una
especfica para el desarrollo de aplicaciones mviles.

2.1 Metodologas de Desarrollo

Tras una reunin
4
llevada a cabo en febrero del 2001, nace el concepto de
metodologas de desarrollo "gil" aplicado al desarrollo software. La principal meta
era conseguir que los proyectos de software no se dilaten y exista una gestin de
cambios de tal manera que sean accesibles a cambios durante el desarrollo. Esto
en respuesta a las metodologas de desarrollo de aplicaciones tradicionales,
definidos por su carcter rgido e intolerantes en el sentido de la documentacin.

La aparicin de estas metodologas giles aparentemente fue un reflejo del alto
nmero de proyectos que terminan en el fracaso o se toman ms tiempo del
estimado y la calidad no mejorada ni explotada por parte de proyectos de
desarrollo de software, as lo cree [4]. Una vez asentados estos conceptos se
establece The Agile Alliance
5
, propuesta a extender la nueva nocin de
Desarrollo de software gil destacando la creacin de conceptos contenidos en
el Manifiesto gil
6
, conceptos y valores [5] primordiales como:

El individuo y las interacciones del equipo de desarrollo estn por encima
del proceso y las herramientas. Construir un buen equipo y que ste
configure su propio entorno de desarrollo en base a sus necesidades.
Desarrollar software que funciona ms que conseguir buena
documentacin. No producir documentos a menos que sean necesarios de

4
Ia re+$i$ se #ele,r e$ fe,rero de 2001J e$tre el 11 / el 13 de ese mesJ e$ *$ow,irdJ +$a esta#i$ de s>i
m+/ #o$o#idoJ sit+ada e$ las mo$taDas :asat#?. %l ma$ifiesto lo firmaro$ 17 a+toresJ ' Pe$t 3e#>J
Mi>e3eedleJ 2rie va$ 3e$$e>+mJ 2listair.o#>,+r$J :ard .+$$i$g?amJ Marti$ 6owlerJ @ames =re$$i$gJ
@imAig?smit?J 2$drew A+$tJ <o$ @effriesJ @o$ Per$J 3ria$ Mari#>J <o,ert .. Marti$J *teve MellorJ
Pe$*#?wa,erJ @eff *+t?erla$dJ Dave B?omas) represe$ta$tes de las por e$to$#es ms pop+lares /
moder$as metodologas 0+e a partir de e$to$#es pasara a #o$o#erse #omo QgilesRJ #omo e(treme
"rogrammi$gJ .r/stal .learJ "ragmati#"rogrammi$gJ D*DM o 2*D.
5
?ttp!OOwww.agileallia$#e.orgO
6
2gile Ma$ifestoJ ?ttp!OOagilema$ifesto.orgO
22

una forma inmediata. Si el software no funciona, los documentos no valen
de nada.
La colaboracin con el cliente es ms importante que la negociacin de
contratos. Tiene que haber una interaccin constante entre el cliente y el
equipo de desarrollo.
La respuesta ante el cambio es ms importante que el seguimiento de un
plan. La planificacin no debe ser estricta sino flexible y abierta, la
habilidad de responder a los cambios que surjan determina el xito o
fracaso del proyecto.

2.1.1 Metodologas agiles para desarrollo de software mvil

Aunque existen un amplio nmero de metodologas de desarrollo de software
giles
7
, ninguna se ha centrado en el entorno y en la caracterizacin que el
desarrollo de software para mviles necesita. Pero lo que s se puede apreciar es
que dichas metodologas coincidan con ciertos valores o criterios apreciables al
desarrollo dirigido para plataformas mviles.

En forma de un anlisis comparativo, se presenta la igualdad de criterios de los
mtodos giles sobre el desarrollo de software para mviles partiendo de una
motivacin lgica, que se muestra en la Tabla 2 (adaptacin de [6]).

Caractersticas
giles
Motivacin lgica En el caso del desarrollo
para plataformas mviles
Alta volatilidad
del
entorno
Debido a la alta frecuencia en el
cambio que sufren los
requerimientos, tendremos
menos necesidad de diseo y
planificacin inicial y mayor
necesidad de desarrollos
incrementales e iterativos.
Alta incertidumbre,
entornos dinmicos,
cientos de nuevos
terminales cada ao

7
%$tre las 0+e ?a$ #o$tado #o$ ms a#epta#i$ podemos desta#ar 2daptive *oftware Developme$tJ la
familia de metodologas .r/stalJ el MGtodo de Desarrollo de *istemas Di$mi#os 'D/$ami# */stem
Developme$t Met?odolog/J D*DM)J e(treme"rogrammi$g '(")J 6eat+re-Drive$Developme$t '6DD)J Iea$
*oftwareDevelopme$tJ *#r+mJ 2gile Modeli$g o "ragmati#"rogrammi$gJ 2gile Model-Drive$Developme$tJ
2gileC$ified"ro#essJ <atio$alC$ified"ro#ess.
23

Equipos de
desarrollo
pequeos
Capacidad de reaccin ms
rpida, trabajo basado en la
comparticin de la informacin,
menos documentacin.
La mayor parte de los
proyectos de desarrollo
software para plataformas
mviles se lleva a cabo en
microempresas y Pyme.
Cliente
identificable
Desaparecen los malentendidos. Potencialmente, hay un
nmero ilimitado de
usuarios finales, pero los
clientes son fciles de
identificar.
Entornos de
desarrollo
orientados a
objetos
Mayora de las herramientas de
desarrollo gil existen bajo
plataformas orientadas a
Objetos.
Por ejemplo, Java y C++
se usan, algunos
problemas en
herramientas como
refactorizaciones o
primeros tests.
Software crtico
no asegurado
Los fallos no causan gran
impacto, como la prdida de
vidas. Se puede buscar mayor
agilidad en el desarrollo.
La mayora del software es
para entretenimiento. Los
terminales no son fiables.
Software a nivel
de aplicacin
Sistemas embebidos grandes
requieren comunicacin
exhaustiva y mecanismos de
verificacin.
Mientras los sistemas
mviles son complejos y
altamente dependientes,
las aplicaciones son muy
autnomas.
Sistemas
pequeos
Menos necesidad de diseo
inicial.
Las aplicaciones, aunque
variables en tamao, no
suelen superar las 10.000
lneas de cdigo.
Ciclos de
desarrollo
cortos
Propsito de realimentacin
rpida.
Periodos de desarrollo de
1 a 6 meses.
Tabla1. .omparativa e$tre #ara#tersti#as del desarrollo gil / del desarrollo mvil

Aunque la forma de desarrollar aplicaciones para un entorno o plataformas
mviles no est exenta de los problemas presentados con el desarrollo de
aplicaciones convencionales, se ha estimado que la corta duracin del desarrollo
que las plataformas mviles exigen es relativamente corta. Esto interviene a la
hora de optar por una metodologa especfica de desarrollo.

El mayor beneficio de una metodologa especfica para el desarrollo es sin duda la
organizacin de tareas, sistematizacin del procedimiento y sobretodo un modelo
esttico y predictivo que administre las tareas y adems, nos informe
24

intuitivamente la situacin del proyecto en cualquier perodo de tiempo en que nos
lo preguntemos. A continuacin, vamos a analizar una serie de metodologas
aplicables, bajo los criterios antes mencionados, para el desarrollo de
aplicaciones mviles:

2.1.1.1 Desarrollo gil: Programacin Extrema (XP)

Formulado y creado inicialmente por Kent Beck es el ms destacado de los
procedimientos giles de desarrollo de software. La programacin extrema se
diferencia de metodologas tradicionales en que se encarga de la adaptabilidad y
la previsin a la gestin de cambios y a los temas relacionados a la metodologa.
Adeptos a esta metodologa aseguran que los cambios de requerimientos no es
algo fuera de lo comn, es ms, siempre han sido considerados y algunas veces
hasta deseados a diferencia de otras prcticas. Se pretende que una gestin de
cambios activa en cualquier punto del proyecto representa y simboliza una
aproximacin ms realista que definir todos los requerimientos al comienzo y
sobre invertir energas en tratar de controlar la gestin de cambios en dichos
requerimientos.
Esta metodologa tiene cinco valores mencionados a continuacin:

Simplicidad
En este valor se basa toda la programacin extrema, se agilita el desarrollo y
se facilita el mantenimiento al tratarse de una implementacin sencilla. Aunque
se trata en esta metodologa de cuidar la simplicidad, las sucesivas
modificaciones del cdigo y de su diseo hacen que aumente la complejidad.
Refactorizando el cdigo, se mantiene este principio mientras el cdigo crece
con las mltiples modificaciones. Asimismo, la simplicidad se mantiene en la
documentacin, juntamente con el desarrollo del cdigo se comenta en justa
25

medida y sin sobre esforzarse, manejando estndares de tal manera que se
cuide la auto documentacin
8
de dicho cdigo.

Comunicacin
La programacin adems de reflejar la simplicidad muestra la comunicacin
que este tenga. La comunicacin es primordial y mejor mostrada cuando el
cdigo es simple. Si el cdigo es complejo, debe esforzarse y tratar a toda
costa de hacerlo inteligible.
Las pruebas unitarias de una u otra forma transmiten informacin acerca del
diseo de sus clases y de ciertos mtodos al mostrar formaciones concretas
de cmo utilizar la funcionalidad. Gracias a la programacin en parejas, la
comunicacin se muestra constantemente entre desarrolladores. La
comunicacin con el cliente es de manera directa ya que el equipo de
desarrollo integra al cliente tambin gracias a la filosofa de la metodologa.

Retroalimentacin (feedback)
Mientras el cliente, segn la filosofa de la metodologa, est al tanto del
desarrollo dentro del proyecto, su opinin y su perspectiva del mismo es
considerado en tiempo real. Las iteraciones cortas hacen que se muestren
tanto los resultados y su proyeccin en el proyecto en el instante que est
ocurriendo.
El desarrollo y planificacin de pruebas tienen embebido este valor a travs de
su especificacin, por ejemplo, las pruebas y anlisis de resultados muestran
la calidad y sobreestima del cdigo dentro de la solucin.

8
"ara esto se de,e elegir ade#+adame$te los $om,res de las varia,lesJ mGtodos / #lases.
26

Coraje o valenta
Este valor es fundamental para reconstruir cdigo cuando sea necesario o
cuando el requerimiento esbozado por el usuario amerite su replanteamiento.
Con esto, se evita empantanarse en el diseo y a su vez estimar demasiado
tiempo en su dedicacin para la implementacin. En el diseo tambin es
fundamental a la hora de planificarlo para satisfacer las necesidades a corto
plazo para estimar el tiempo y no centrarse en el trabajo a futuro.
La valenta tambin est asociada en la moral del desarrollador para desechar
el cdigo que no sirve o a su vez, ha perdido a travs del tiempo su
funcionalidad. Este valor se relaciona a pesar de cuanto esfuerzo, tiempo y
recursos se hayan requerido para su implementacin.

Respeto
Valor fundamental y de carcter moral. Gracias a este existe un ambiente de
respeto y armona entre desarrolladores, como la implementacin es
colaborada se respeta el esfuerzo y los recursos usados por un desarrollador
en un momento especfico. Adems, no se pueden hacer cambios, adiciones,
modificaciones ni eliminacin de cdigo que implique que las pruebas fallen o
que demore ms trabajo en su construccin.

2.1.1.2 Desarrollo gil: Scrum

Ms que una metodologa, es un marco de trabajo para el desarrollo de software,
bajo un proceso iterativo e incremental usado para ambientes de desarrollo
basado en desarrollo gil de software.
Orientado inicialmente en gestin de procesos de desarrollo de software, puede
ser usado en equipos de mantenimiento de software.
27

Scrum define un conjunto de roles y prcticas y se toma como un punto de partida
para definir procesos de desarrollo, en los cuales, la estima de los recursos
humanos es primordial. Scrum maneja varios roles dentro de la metodologa como
el Scrum Master, el Product Owner y en general, se hace referencia a el Team.
El Scrum Master es el encargado de la direccin del proyecto; mientras que el
Product Owner se encarga de la gestin de los stakeholders o interesados del
proyecto, tanto internos como externos, y el Team o equipo de desarrollo
encargado de la implementacin.
Sus perodos iterativos denominados sprint comprenden un perodo entre una y
cuatro semanas. Estn conformados y designados por el equipo de desarrollo,
este equipo definir un entregable que ser un incremento de software
potencialmente utilizable.
El Product Backlog es un conjunto de requerimientos de alto nivel que poseen una
prioridad definida y establecen los parmetros fijos y precisos enfocndose en el
esfuerzo que se realizar. Este Product Backlog definir las caractersticas de
cada sprint y su realizacin.
El procedimiento se realiza desde el punto de vista del Product Owner que
identifica los elementos que contendr el Product Backlog y se los define en la
reunin de Sprint Planning. El Team analiza la cantidad de esfuerzo y se plantea
si se puede o no realizar dicho trabajo en el siguiente Sprint. Durante el desarrollo
de Sprint en ejecucin, no se aceptan cambios dentro del tiempo que este durara,
dando as la certeza de que la gestin de cambios se encuentra congelada
durante el perodo de tiempo determinado que durar el sprint.
Se permiten los equipos auto-organizados dentro del desarrollo, considerando la
comunicacin verbal de los miembros y dems disciplinas dentro del proyecto.
Una ventaja por sobre otras metodologas y procesos de desarrollo de software es
que Scrum es muy fcil de aprender y requiere poco esfuerzo tanto de
interesados en el proyecto como desarrolladores para utilizar inicialmente.

La desventaja mayor indicada es que, aunque su gestin de cambios sea
actualizada en gran medida y propuesta directamente por el cliente, no es tan
flexible como otras metodologas giles de desarrollo de

2.1.1.3 MobileD

Esta metodologa[7] nace como demanda de un proyecto finlands, ICAROS
en el ao 2004.El inicio de esta metodologa es interesante al considerar aspectos
como que esta es una mezcla de muchas tcnicas para el desarrollo. Basado en
metodologas conocidas pero aplicadas de forma multi
Programming, Crystal Methodologies y Rational Unified Process.
suma importancia y que le da un peso dife
esta fue desarrollada en un marco de cooperacin con la industria de dicho pas,
aportando a la metodologa, las prestaciones que reciben las aplicaciones y el
desarrollo comercial.
Se compone de distintas fases:
de estabilizacin y la fase de pruebas. Cada una tiene un da de planificacin y
otro de entrega.
Figura1. 6ases de la meto
flexible como otras metodologas giles de desarrollo de software.
nace como demanda de un proyecto finlands, ICAROS
a mezcla de muchas tcnicas para el desarrollo. Basado en
metodologas conocidas pero aplicadas de forma multi - variable como: Extreme
Programming, Crystal Methodologies y Rational Unified Process.
suma importancia y que le da un peso diferenciador a otras metodologas es que
Se compone de distintas fases: exploracin, inicializacin, fase de producto, fase
. 6ases de la metodologa para desarrollo mvil Mo,ile
e&plora#i$
i$i#iali8a#i$
fase de
prod+#to
fase de
esta,ili8a#i$
fase de
pr+e,as
28
software.
nace como demanda de un proyecto finlands, ICAROS[8],
a mezcla de muchas tcnicas para el desarrollo. Basado en
variable como: Extreme
Programming, Crystal Methodologies y Rational Unified Process. Otro aspecto de
renciador a otras metodologas es que
exploracin, inicializacin, fase de producto, fase

Mo,ile-D
29

Fase de exploracin

Inicialmente, se centra la atencin en la planificacin y a los conceptos
bsicos del proyecto. Aqu es donde hacemos una definicin del alcance
del proyecto y su establecimiento con las funcionalidades donde queremos
llegar.

Fase de Iniciacin

En esta configuramos el proyecto identificando y preparando todos los
recursos necesarios como hemos comentado anteriormente en esta fase la
dedicaremos un da a la planificacin y el resto al trabajo y publicacin.

Fase de producto

Se repiten iterativamente las sub-fases. Se usa el desarrollo dirigido por
pruebas (TDD), antes de iniciar el desarrollo de una funcionalidad en una
iteracin, debe existir una prueba que verifique su funcionamiento. En esta
fase podemos decir que se lleva a cabo toda la implementacin.

Fase de estabilizacin

Fase en la que se realizan las acciones de integracin para enganchar los
posibles mdulos separados en una nica aplicacin.

Fase de pruebas

Fase donde se har testeo hasta llegar a una versin estable segn lo
establecido en las primeras fases por el cliente. Si es necesario se reparan
los errores, pero no se desarrolla nada nuevo.

30

Una vez acabadas todas las fases, deberamos tener una aplicacin publicable y
entregable al cliente.
Mobile-D se basa en Extreme Programming (prcticas), Metodologas de Cristal
(escalabilidad) y Rational Unified Process (cobertura). La documentacin
completa de esta metodologa se puede encontrar disponible en el sitio web del
proyecto[9].

2.1.2 Caractersticas y requerimientos especficos del entorno mvil

El Modelamiento, la construccin as como la implementacin de aplicaciones
mviles generan diferencias importantes con respecto al desarrollo de
aplicaciones para escritorio. Es por esto que, las metodologas aplicadas para el
desarrollo en plataformas mviles dista de las metodologas tradicionales. Esto se
debe a que el software implementado tiene que satisfacer requerimientos [10],
[11] y condiciones especiales[12] que generan desproporciones tanto de
infraestructura, arquitectura, modelado y/o inclusive condiciones fsicas y de
hardware. Estas condicionantes hacen que el desarrollo en mviles se vuelva un
tema complejo:

Radio frecuencia

La disponibilidad como valor fundamental de esta condicionante hace que
el tema, por ejemplo, de las conexiones o desconexiones a la red,
variabilidad del ancho de banda, heterogeneidad de redes o los riesgos de
seguridad deban tomarse en cuenta para el correcto acaparamiento y
definicin de riesgos en la operacin dentro del entorno de comunicaciones
mviles.

Movilidad

Se consideran aspectos como el de direcciones dinmicas, movilidad de
31

redes, adems de la alta latencia debido a la referencia mvil y
propiedades de las redes de telefona cambiante a travs de las
denominadas clulas
9
y su gestin de la informacin relacionada
exclusivamente con su localizacin. Aunque dicha localizacin muchas
veces es una ventaja competitiva frente al mundo de las aplicaciones y sus
usos, asimismo, provee una limitacin con respecto a su conectividad.

Portabilidad

Esta caracterstica est ms bien orientada a: la factibilidad de los
dispositivos mviles, a su fcil traslado, aprovechando su tamao, forma,
etc. Aunque es un factor de forma, no es menos importante, ya que se
tiene en cuenta por ejemplo, el tamao de las pantallas (algo que ha
evolucionado esencialmente con la utilizacin de pantallas tctiles), o de
igual manera el teclado, restringiendo tambin el tamao usado para la
escritura y su forma.

Fragmentacin delaindustria

El hecho que exista una inmensa diversidad de protocolos, estndares y un
conjunto de tcnicas de red diferentes es una complicacin ms hacia la
etapa de desarrollo para mviles.

Capacidades limitadasdelosterminales

Como es de esperarse y como un medio de factibilidad hacia el atributo
concerniente a la portabilidad y movilidad, se incluye agentes limitantes
propios de los dispositivos estudiados, como es la baja potencia de clculo
o grfica, los riesgos en la integridad de datos, las interfaces de usuario
poco funcionales en muchos aspectos, la baja capacidad de

9
.ada a$te$a es +$a #Gl+la i$ter#o$e#tada e$ forma de mallaJ 0+e reali8a$ el e$la#e e$tre los aparatos /
las esta#io$es de ,ase. Ias esta#io$es re#epta$ las fre#+e$#ias / las tra$smite$ de +$as #Gl+las o esta#io$es
a otrasJ ?asta llegar al desti$o re0+erido. Ias redes de telefo$a mvil p+ede$ ser a$algi#as o digitales.
32

almacenamiento, la duracin de las bateras o la dificultad para el uso de
perifricos en movilidad. Estos factores estn avanzando y evolucionando
por el camino de la aproximacin de las ultra-porttiles
10
con los
dispositivos inteligentes, constituyendo cada vez menos un elemento
diferencial.

Diseo

Esta propiedad es una de las propiedades que ms cambia a diferencia del
desarrollo y construccin de sistemas de escritorio. Se diferencia
notoriamente del diseo desde el punto de vista de la forma propia del
software, y la propiedad multitarea de los diseos tradicionales dista del
diseo minimalista y mono tarea de este desarrollo.

Usabilidad

Al aportar a esta tecnologa el uso de distintos dispositivos, mecanismos y
dems infraestructuras acoplables, se vuelve primordial definir la usabilidad
apropiada del software desarrollado. De esta manera, la utilizacin puede
convertirse en una ventaja, sin contar con el hecho de que las necesidades
especficas de amplios y variados grupos de usuarios hacen que el diseo
llegue a ser un requisito que genere una complejidad creciente difcil de
acotar.

De esta manera, se deja en claro que el desarrollo y, principalmente, el diseo es
mucho ms complejo que el desarrollo tradicional contemplado en otros proyectos
de desarrollo. Es por ello que, se ha tenido que deliberar sobre el planteo de otras
metodologas de desarrollo de software para el tratamiento de sistemas mviles,
como son el uso de metodologas giles. Estas ltimas se han acercado ms al
desarrollo para plataformas mviles, aunque las propiedades y caractersticas
mencionadas anteriormente propias de estos dispositivos y la naturaleza de las

10
Cltra,oo> es +$ tipo de orde$ador porttil livia$o. Defi$ido por 7$tel e$ el aDo 2011 es +$a i$i#iativa por
parte de Gsta para #rear +$ mer#ado ". e$ #ompete$#ia #o$ el Ma#3oo> 2ir de 2pple.
33

redes de telefona mvil requiere que se hagan todava ajustes sobre las actuales
metodologas giles.

2.2 Arquitecturas

2.2.1 SOA

La arquitectura orientada a servicios, tambin llamada por sus siglas SOA11. Es
una arquitectura paradigma que tiene como objetivo brindar agilidad, soporte y
funcionalidad a servicios con el fin de satisfacer al negocio directamente. Permite
la construccin de sistemas y el enriquecimiento de otros ya existentes de forma
que sean escalables y tengan una demanda directa de servicio.
Aunque en el mundo y mbito tecnolgico se use para distinguir una arquitectura
y un paradigma, se tiene en cuenta que SOA es ms bien un paradigma que
define y aporta tcnicas para abordar el negocio directamente en la arquitectura
de las aplicaciones por medio de los servicios.
Utilizando un lenguaje apropiado, se puede construir por medio de este
paradigma elementos de software discretos, modulares, escalables y reutilizables
llamados servicios.
Estos servicios creados tiene la facilidad de convertirse en recursos y esta
filosofa adopta esta gestin de cambio de manera que estos recursos sean
accesibles desde las aplicaciones y diversos sistemas dentro de la organizacin.
De esta manera, para generar la automatizacin correcta de los procesos de
negocios descritos
12
nicamente bastar con llamar a ciertos servicios en un orden
especfico. A este proceso se denomina orquestacin
13

11
*ervi#e 1rie$ted 2r#?ite#t+re
12
"or lo ge$eral e$ diagramas +tili8a$do le$g+a5e de modelado 3"M;.
13
*e#+e$#iar los servi#ios / proveer la lgi#a adi#io$al para pro#esar datos.
34

2.2.2 !M

La Administracin de Procesos de Negocio o por sus siglas BPM
14
es una
metodologa cuyo principal objetivo es el de satisfacer los tiempos de
mejoramiento para acelerar las tareas de eficiencia de las organizaciones. Esto lo
hace, a travs de una correcta gestin de los procesos de negocio.
Dentro de esta filosofa, los procesos de negocio son activos que tienen y se
deben poder administrar. El modelado permite de manera clara hacerlos explcitos
y visibles para las diferentes etapas de su gestin. Asimismo, el monitoreo de
estos procesos de negocio permitir corregir problemas internos y externos del
proceso y se tendr la oportunidad de optimizar.

2.2." #enta$as que aporta !M a SOA

Los diagramas de BPM aportan como su descripcin lo sugiere la visibilidad
necesaria para contribuir e identificar los requerimientos natos de los procesos de
negocio de una manera clara y oportuna. La identificacin de estos
requerimientos, que por lo general son comunes para varias etapas, desemboca
en la creacin de servicios SOA que a su vez son reutilizables.
Identificando este patrn de desarrollo, estos servicios SOA pueden ser llamados
desde varios procesos de negocio. Asimismo, cuando se requiera tratar de
implementar cambios a un proceso de negocio explcito, se proceder a cambiar
nicamente su orquestacin. Esto se refiere al orden o la forma en cmo se llama
un servicio, tambin si en los cambios se tiende a crear nuevos desarrollos de
servicios para sustituirlos con otros y dar respuesta a nuevas necesidades y
requerimientos.

14
3+si$ess "ro#ess Ma$ageme$t.
35

Estos tipos de cambios generan desarrollos ms cortos con este tipo de modelado
y en este tipo de desarrollo se habla de das en vez de meses, como ocurrira en
diferentes estilos de desarrollo y diferentes filosofas.

2.2.% #enta$as que aporta SOA a !M

Desde el punto de vista del negocio, el paradigma y arquitectura SOA es un
habilitador de iniciativas BPM.
Esto quiere decir que SOA aporta con unamodularidad y una escalabilidad que
hace que se proyecte el proceso de negocio de una forma clara. Igualmente,
consiste en identificar a aquellos procesos que pueden cambiar con ms
frecuencia y las razones de porque sucede dicho cambio.
SOA permite que los sistemas que se encuentran encargados de la
automatizacin de los procesos de negocio sean ms flexibles y respondan con
mayor agilidad a la gestin de cambio que requiere el negocio.

2.3 Seleccin de Metodologa

2.".1 Motivacin

Para el desarrollo de una aplicacin mvil para recuento de stocks e inventarios
trasferida mediante Web Services, se debe emplear una metodologa estable y
sobretodo que sea capaz de asegurar un desarrollo posible de la produccin de la
aplicacin en el sector industrial real. Adems de mencionar una metodologa gil
donde se est pensado un desarrollo para grupos no mayores a 10
desarrolladores colaborando en un mismo entorno fsico. Es por ello que se ha
36

escogido trabajar con la metodologa gil para aplicaciones y desarrollos mviles
Mobile-D.
Dicha metodologa propone que si se trabajan el ciclo de desarrollo propuesto,
los proyectos deberan finalizar con el lanzamiento de productos completamente
funcionales
15
en menos de diez semanas[13]

2.".2 !rincipios &'sicos Metodologa Mo&ile()

La metodologa creada inicialmente para la industria directa, con plataformas
mviles se ha sustentado en otras metodologas ya conocidas. Adems, estas
tienen peso a la hora de la planificacin del desarrollo e ingeniera de software:
extreme Programming (XP) [14], Crystal Methodologies[15] y Rational Unified
Process (RUP)[16].
En lo que se refiere a las prcticas de desarrollo de la metodologa se han
utilizado los principios de la Programacin Extrema, as como se suministra un
input valioso de la escalabilidad
16
de los mtodos gracias al aporte de las
metodologas Crystal. Todo esto basndose en el diseo justo del ciclo de vida
que ha proporcionado la metodologa Rational Unified Process.

Programacin
Extrema
Metodologas
Crystal
RationalUnifiedProcess
Aporte de las prcticas de
desarrollo
Aporte Escalabilidad,
gestin de cambios
Aporte del diseo del ciclo
de vida
Tabla2. 2portes de diversas Metodologas2giles a Mo,ile-D

15
2seg+rar 0+e di#?o prod+#to f+$#io$a tal #omo esta,a espe#ifi#ado.
16
.o$fig+ra#i$ para adaptarse a las #ir#+$sta$#ias o re0+erimie$tos #am,ia$tes.

El ciclo de vida del proyecto
fases o etapas: exploracin, inicializacin,
finalmente pruebas del sistema (figura
La metodologa pretende fomentar el desarrollo iterativo
para obtener un desarrollo ms productivo, es por ello, que las fases (excepto la
fase de exploracin) tienen tres
planificacin, trabajo y liberacin
tarea.Se aadir tiempo adems para las tareas adicionales que se requerirn
para culminar el desarrollo de cada etapa.
El siguiente grafico [9] muestra el ciclo de
desarrollo de aplicaciones
Figura

2.3.2.1 !ase "e Ex#loracin

La primera etapa del ciclo de vida refleja, en su diferencia no muy notable al
de etapas, el establecimiento del proyecto y
marcada. Tiene tres etapas: establecimiento de los Stakeholders, definicin del

17
.orrespo$die$te a la ra8 e$ s+ idioma origi$al 'i$gles) de S
El ciclo de vida del proyecto dentro de la metodologa Mobile-D se divide en cinco
: exploracin, inicializacin,productizacin
17
, estabilizacin
del sistema (figura 2).
La metodologa pretende fomentar el desarrollo iterativo lo ms rpido posible
fase de exploracin) tienen tres etapas de desarrollo cambiante destinados a la
planificacin, trabajo y liberacin[13], la metodologa sugiere un
Se aadir tiempo adems para las tareas adicionales que se requerirn
para culminar el desarrollo de cada etapa.
muestra el ciclo de desarrollo de la metodologa
desarrollo de aplicaciones mviles Mobile-D.
Figura2. .i#lo de desarrolloJ metodologa Mo,ile-D.
x#loracin
La primera etapa del ciclo de vida refleja, en su diferencia no muy notable al
stablecimiento del proyecto y su planificacin inicial debidamente

.orrespo$die$te a la ra8 e$ s+ idioma origi$al 'i$gles) de Sprod+#ti8atio$T.
37
se divide en cinco
, estabilizacin y
lo ms rpido posible
de desarrollo cambiante destinados a la
a metodologa sugiere un da para cada
Se aadir tiempo adems para las tareas adicionales que se requerirn
metodologa para el

La primera etapa del ciclo de vida refleja, en su diferencia no muy notable al resto
su planificacin inicial debidamente
38

alcance del proyecto y el establecimiento general del proyecto. La metodologa en
sus inicios propone una cooperacin y participacin activa de los clientes en esta
fase ya que se generarn los requerimientos inciales y su alcance funcional.

2.3.2.2 !ase "e $niciali%acin

En esta etapa los productores
18
identifican, analizan y determinan los recursos
primordialmente necesarios en primera instancia para la generacin del
producto
19
. Se hace un desarrollo y aprovisionamiento de planes y documentacin
definida para las siguientes etapas. Adems, y de suma importancia, se establece
el enfoque y entorno tcnico y tecnolgico incluyendo en este, la capacitacin y
adiestramiento al crew
20
o equipo de desarrollo necesario para poder empezar a
trabajar.
Los autores de esta metodologa aseguran que su principal aporte al desarrollo
gil se encuentra y se apoya en esta etapa, delimitando y fortaleciendo el sondeo
y la investigacin con respecto a la lnea arquitectnica. Adems, define el
esquema en forma macro
21
de servicios que serngenerados.
Esto se conceptualiza durante el da de planificacin. Se examinan el
conocimiento y los patrones arquitectnicos usados por los clientes (si estos
existen) o usados por los desarrolladores en ocasiones anteriores y a estos, los
relacionan con el proyecto actual en curso.
Se aaden comentarios, observaciones, se identifican diferencias y semejanzas
entre casos de estudio y se toman decisiones sobre soluciones posibles para la
implementacin del proyecto.

18
;tese #omo prod+#tores a los desarrolladores del prod+#to si$ tomar e$ #+e$ta a los #lie$tes.
19
<e0+erimie$tos satisfe#?os media$te la fase de pr+e,as.
20
%0+ipo BG#$i#o rela#io$ado a los prod+#tores.
21
De forma ampliame$te ge$eral rela#io$ada al prod+#to.
39

2.3.2.3 !ase "e &Pro"ucti%acin&

En esta fase se repite el patrn de la metodologa por das y tareas especficas
(planificacin, trabajo, liberacin) y se ejecutan estas a travs de iteraciones hasta
llegar a satisfacer todas las funcionalidades. Se podra decir que, en esta fase de
la metodologa se concentra el trabajo realizado por desarrolladores al momento
de implementar tecnologa. Los das y las tareas especficas se resuelven de la
siguiente manera:

Planificacin
Se contempla la iteracin de establecimiento de requisitos y tareas concretas
por cumplir. Se realiza la implementacin de requisitos para pruebas de
iteracin anterior (se utiliza el Desarrollo guiado por pruebas TDD
22
[17]).
Trabajo
Dichos requerimientos por cumplir son satisfechos en el correspondiente da
de trabajo produciendo el cdigo, subiendo a repositorios diseados para la
integracin y la unificacin del mismo.
Liberacin
La integracin y composicin del sistema ocurre en este da, destinado para el
armado de cdigo (si hubiera dos o ms equipos de desarrollo de forma
independiente) y las pruebas adecuadas y ajustadas para su verificacin.

2.3.2.' !ase "e Estabili%acin

Las ltimas labores de unificacin del cdigo e integracin se obtienen en esta
etapa garantizando que el cdigo combinado e implementado funcione fielmente
apegado a los requerimientos. En los equipos de desarrollo conformados por

22
Best-drive$ developme$t 'BDD)
40

varios grupos de desarrolladores, esta fase es primordial ya que se afina la
integracin entre componentes o subsistemas desarrollados.
Se considera tambin, en esta fase la generacin de documentacin.

2.3.2.( !ase "e Pruebas

Esta que es la ltima fase del proyecto posee el trmino de obtener un release
funcional y con la suficiente estabilidad necesaria y requerida. El entregable
terminado se prueba hacia los requerimientos del cliente y si se encuentran
defectos en dicho entregable se hace una iteracin ms para eliminarlos.

2."." *nfoque pragm'tico

En un enfoque prctico y pragmtico de la metodologa, los autores han obtenido
una certificacin del tipo CMMI
23
denivel2
24
, el cual les otorga una garanta al
momento del desarrollo con esta metodologa. Esta sin duda, es una ventaja
diferenciadora de gran importancia contra otras metodologas giles de desarrollo,
ya que una Mobile-D al ser una metodologa probada y creada para el sector
industrial de aplicaciones de su pas de origen
25
. Entonces, es una metodologa
que cuenta con mtricas de aseguramiento de calidad aceptadas en el sector y
CMMI es una de las mtricas.
Los autores de la metodologa afirman, adicionalmente, que la implementacin de
esta se encuentra basada en casos de estudio reales en los cuales se ha aplicado
y se ha obtenido experiencia al usarla. Se inici con una base de cuatro
aplicaciones de la metodologa[13]. Adems, aseguran que los ciclos de vida de
la metodologa han mejorado en base a la experiencia de muchos aos de
trabajo.[18]

23
?ttp!OOwww.sei.#m+.ed+O#mmiOge$eralOi$de&.?tml
24
?ttp!OOagile.vtt.fiOprodserv.?tml
25
6i$la$dia
41

2.4 Seleccin de herramientas de desarrollo

El proyecto consta de dos etapas, la primera a desarrollarse en el dispositivo
mvil, el cual consumir Web Services y se har la toma de inventario; y, el
mecanismo en el servidor que gestionar y administrar los servicios basados en
Internet que gestionarn las comunicaciones con el dispositivo mvil.

2.%.1 Servicios +e&

El portal de Wikipedia[19], afirma que Un servicio web (en ingls, Web Service)
es una pieza de software que utiliza un conjunto de protocolos y estndares que
sirven para intercambiar datos entre aplicaciones.

Las dos tecnologas ms comunes a la hora de abordar esta temtica son J2EE
26

(Sun Microsystems, hoy Oracle) y .NET
27
(Microsoft).
Tanto los lenguajes que manejan estas tecnologas, Java de J2EE o Visual Basic
.NET o C# de Microsoft .NET, son lenguajes orientados a objetos.

Esta comparativa hace que por caractersticas de implementacin a nivel de
cdigo, los Web Services tengan el mismo grado de dificultad. Por ello, la
determinacin de la tecnologa a usarse se ver reflejada en las caractersticas de
cada tecnologa con respecto a ventajas y desventajas sobre un anlisis
comparativo. Este ltimo, se basar en beneficios de cada plataforma de
desarrollo y ciertas caractersticas y tecnologas asociadas como son: el nivel de
informacin, comunicacin, descripcin, localizacin, seguridad y mejoras a las
cuales se puede consentir mediante actualizaciones con respecto a cada
plataforma.

La tabla a continuacin presentada muestra una sntesis de tecnologas usadas
en Web Services por las plataformas .NET y J2EE respectivamente.

26
@ava 2 %$terprise %ditio$
27
4is+al *t+dio .;%B
42

PLATAFORMAS
T
E
C
N
O
L
O
G
I
A
S

.NET J2EE
Informacin XML 1.0, XSD
Path 1.0, XSD, XSLT 1.0
Core DOM Level 1
Core DOM Level 2
XML 1.0, XSD
XPath 1.0, JAXB 1.0
JAXP 1.2, XSLT 1.0
SAX 1.0 y 2.0, DOM 1.0 y 2.0
Comunicacin SOAP 1.1, 1.2 JAX-RPC (SOAP 1.1, 1.2)
Descripcin WSDL 1.1 JAXR 1.0 (WSDL 1.1)
Localizacin UDDI 2.0 UDDI 2.0, ebXML
Seguridad WS-Security (WSE) WS-Security (XWSS)
Mejoras WSE 3.0
MTOM (WS-Attachments)
JWSDP 2.0
SAAJ 1.2 (SOAP withAttachments)
Tabla3. Be#$ologias 2so#iadas 2 .;%B H @2%%

El desarrollo de Web Services dentro de cada plataforma aunque tienen mucha
similitud entre s, presenta diferencias que pueden ser tomadas como ventajas y
desventajas entre los dos tipos de tecnologas. Para analizar la alternativa que se
implementar se presenta a continuacin, una tabla describiendo sus diferencias
generales entre las plataformas .NET y J2EE .

PLATAFORMAS
C
A
R
A
C
T
E
R
I
S
T
I
C
A
S

.NET J2EE
Plataforma implementada y soportada principalmente
poruna sola compaa.
Especificacinelaborada y soportadapor un gran nmero de
compaas.
Implementacin de los servicios Web desde la etapa
de diseo.
Especificacin realizada anteriormenteal surgimiento de los
servicios Web.
Plataforma pensada y orientadaa los servicios Web. Inclusin de los serviciosWeb sobre labase de APIs
generados para ello.
La implementacin de lassoluciones se puede
realizarutilizando diferentes lenguajesde
programacin, dependiendonicamente de su
disponibilidadsobre la plataforma .NET.
La implementacin de las solucionessedebe realizar utilizando
nicamenteel lenguaje de programacin Java.
Las soluciones por el momentonicamente se pueden
ejecutarsobre sistemas operativos MS Windows.
Las soluciones se puedenimplementar sobre distintos
sistemasoperativos y sobre distintasarquitecturas de
procesador.
Tabla4. 4e$ta5as o desve$ta5as e$tre .;%B / @2%%

Adems, una de las ventajas de la plataforma de Windows es que la curva de
43

aprendizaje de.NET es ms baja que J2EE. Esto se debe a que al programar en
esta plataforma se tienen muchos lenguajes de programacin a utilizar en el
Framework de .NET.Tan solo una experiencia mnima a cualquier lenguaje de
esta naturaleza satisface desde ya una ventaja comparativa frente a la
implementacin de la solucin.

El soporte para el framework de .NET es mucho ms definible y ofrece muchos
servicios de contenido tanto procedente de terceros como de Microsoft.

En el caso de la plataforma para Web Services de Java, J2EE, la informacin
representativa que se encuentra hace referencia a la especificacin y detalles
tcnicos. Aunque existen sitios tambin de terceros con informacin considerable,
se estiman una proporcin aproximada de 1 sitio por cada 15 de .NET
(informacin obtenida por el autor sobre la base de bsquedas en el motor de
bsqueda Google).

Se encuentra con ms fuentes de informacin y soporte la plataforma .NET de
Microsoft, aunque ambas opciones y alternativas estn contempladas como
capaces para solventar y sostener la implementacin del presente proyecto.Esto
tomando en cuenta soluciones con Web Services que respeten
especificacionesactuales y de compatibilidad tanto operativas como seguridad.

De esta manera, se analiza como opcin ms recomendada la opcin de esta
plataforma propietaria para la implementacin de Web Services dentro del
presente proyecto.

2.%.2 Aplicacin Mvil ,ativa

El proyecto se centrar en una solucin del tipo nativa
28
, la cual se desarrolla en
la plataforma y sistema operativo mvil basado en Linux de Google, Android.

28
Aa#e refere$#ia a +$a apli#a#i$ diseDada para +$a plataforma e$ parti#+larJ i$stalada / f+$#io$a$do #o$
difere$tes re#+rsos espe#fi#os de di#?a plataforma e$ parti#+lar.
44

Su definicin, Android es un sistema operativo mvil basado en Linux
29
, que junto
con aplicaciones middleware7 est enfocado para ser utilizado en dispositivos
mviles como telfonos inteligentes, tabletas, Google TV y otros dispositivos[20].
Una de las razones para adoptar Android como el sistema operativo para la
implementacin de este proyecto y en si como plataforma principal de desarrollo,
se basa en que es una plataforma de cdigo abierto
30
.

Su promotor, Google, ha publicado varias versiones de SDK
31
para el desarrollo
con esta plataforma, difundindolas libremente.
La forma de programacin en Android es mucha ms intuitiva que otras
plataformas como la desarrollada por Apple, iOS con su lenguaje particular y
propietario Objective-C
32
.
Adems, existen varios motivos para elegir implementar el sistema en esta
plataforma:

2.'.2.1 )#ren"i%a*e

Al obtener el SDK de Android, se requiere para implementar cdigo (en esta
plataforma) conocer el lenguaje de programacin Java
33
. Este lenguaje de
programacin es muy intuitivo, orientado a objetos y de vasta popularidad a nivel
de implementacin.

2.'.2.2 +ele,ante

Se ha notado que la utilizacin de dispositivos mviles est superando a la
utilizacin de computadores de escritorio tradicionales.
En el siguiente grfico proporcionado por el INEC
34
, basado en el ltimo censo

29
;U#leo li,re de sistema operativo ,asado e$ C$i&.
30
BGrmi$o #o$ el 0+e se #o$o#e al software distri,+ido / desarrollado li,reme$te.
31
.o$5+$to de ?erramie$tas de desarrollo de software 0+e le permite al programador #rear apli#a#io$es
para +$ sistema #o$#reto
32
Ie$g+a5e de programa#i$ e$ el 0+e se desarrolla para i1*.
33
Ie$g+a5e de programa#i$ orie$tado a o,5etosJ desarrollado por *+$ Mi#ros/stems a pri$#ipios de los
aDos 90.
34
7$stit+to ;a#io$al de %stadsti#a / .e$sos '%#+ador).

poblacional, se demuestra que la poblacin usa celulares y dispositivos mviles
ms que computadoras.
Figura

2.'.2.3 -"igo )bierto

El Open Source es una tendencia
punto que no se necesita de licencias ni de contratos especiales por adopcin de
uso. Las plataformas mviles apuntan a ser un negocio de alta proyeccin
garantiza la permanencia en el mercado y su uso
importante al momento de licencias, contratos, y prestaciones de servicio

2.%." -ntroduccin a la plataforma Android

Android es una plataforma open Source para smartphones, tabletas y dispositivos
mviles en general, que se complementa con un sistema operativo, un sistema en
tiempo de ejecucin basado en Java, un conjunto de libreras de medio y bajo
nivel y un conjunto de aplicaciones, desarrolladas en Java, destinadas al usuario
final.
demuestra que la poblacin usa celulares y dispositivos mviles

Figura3. "o,la#i$ 0+e +sa #ierto tipo de te#$ologia
El Open Source es una tendencia que ha marcado el software tradicional desde el
uso. Las plataformas mviles apuntan a ser un negocio de alta proyeccin
garantiza la permanencia en el mercado y su uso comercial tiene un factor
importante al momento de licencias, contratos, y prestaciones de servicio
-ntroduccin a la plataforma Android
que se complementa con un sistema operativo, un sistema en
45
demuestra que la poblacin usa celulares y dispositivos mviles

ha marcado el software tradicional desde el
uso. Las plataformas mviles apuntan a ser un negocio de alta proyeccin, lo cual
comercial tiene un factor
importante al momento de licencias, contratos, y prestaciones de servicio.
que se complementa con un sistema operativo, un sistema en
46

La plataforma se distribuye bajo una licencia libre del tipo Apache
35
, que permite
integracin con soluciones del tipo propietarias. La Open Handset Alliance
36
, un
consorcio de 48 empresas distribuidas por todo el mundo con intereses diversos
en la telefona mvil, fue la encargada de dar paso a este Sistema Operativo para
mviles. Adems, de ser un compromiso para su comercializacin en diferentes
estndares de hardware de dichas compaas. Su principal desarrollo recae sobre
Google una vez realizada la compra del Sistema Operativo en el 2005.
Entre estas empresas se encuentran grandes del negocio de las operadoras de
telefona como Telefnica, Vodafone, T-Mobile, fabricantes de mviles (Motorola,
Samsung, Acer, LG, HTC...) o relacionadas al Hardware (nVidia, Intel o Texas
Instruments).

2.'.3.1 )r.uitectura)n"roi"

Como se denota en la figura 4, la Arquitectura de esta plataforma se basa en 4
niveles o capas:

Capa de Aplicaciones

Constituyen un conjunto de aplicaciones que corren en el dispositivo como
base para otras o para el uso normal del telfono. Estas son: telfono,
cliente de email, programa de envo de SMS, calendario, mapas,
navegador, contactos, etc. Y estas pueden ser usadas por otras
aplicaciones. Dentro de esta capa se desarrollar la aplicacin.

Framework de aplicaciones

Se encuentra separado por varios subsistemas y tienen un nmero de
componentes especficos para cada mdulo, por ejemplo el del

35
Ii#e$#ia de software li,re #reada por la 2pa#?e *oftware 6o+$datio$ '2*6)
36
?ttp!OOwww.ope$?a$dsetallia$#e.#om
47

Administrador del telfono, se encarga de la gestin del dispositivo como
hardware. Se puede desarrollar partiendo de la caracterstica de reso de
componentes de cada aplicacin, de esta manera se orienta la arquitectura
para facilitar la reutilizacin de componentes para las aplicaciones.
Estas normas de rehso se rigen bajo controles de seguridad
proporcionados por el framework. Tambin en esta capa se incluye el
sistema de vistas que manejan la UI
37
de las aplicaciones, con capacidades
como el visualizar elementos HTML o el render de mapas en la vista de la
aplicacin.

Capa de bibliotecas de bajo nivel

Escritas en C y C++, sirven para persistencia de datos, gestin de grficos
3D, navegadores web embebidos. Entre estas libreras se encuentran
elementos como SQLite, OpenGL, Webkit, etc.

Kernel Linux

Sirve como una columna importante y fundamental de software la cual se
encarga del sistema de gestin de drivers, seguridad, comunicaciones y
algunas funciones esenciales del sistema.

El siguiente diagrama (reproducido de Wikipedia
38
) contiene el diagrama de
arquitectura por capas del que se compone la plataforma Android.

37
7$terfa8 de +s+ario.
38
?ttp!OOes.wi>ipedia.orgOwi>iO2$droid

Figura 4. Diagrama de ar0+ite#t+ra de la plataforma 2$droid.

2.'.3.2 Desarrollo en la #lata/orma )n"roi"

Android cuenta con una comunidad
tutoriales de manera amigable para hacer el desarrollo de aplicaciones en esta
plataforma una tarea muy sencilla y de esta manera generar un mayor grupo de
aplicaciones generadas para esta tecnologa. Estas pre
descargar directamente y gratuitamente de su pgina web

39
http!OOdeveloper.a$droid.#om
. Diagrama de ar0+ite#t+ra de la plataforma 2$droid.
Desarrollo en la #lata/orma )n"roi"
Android cuenta con una comunidad, la cual presta foros y algunos recursos como
aplicaciones generadas para esta tecnologa. Estas prestaciones se las pueden
descargar directamente y gratuitamente de su pgina web
39
.

48

. Diagrama de ar0+ite#t+ra de la plataforma 2$droid.
la cual presta foros y algunos recursos como
staciones se las pueden

2.'.3.3 Entorno "e Desarrollo

Para el entorno de desarrollo
cuenta con un plugin o adaptador para un IDE
Figura5. .apt+ra de pa$talla del 7D% %#lipse #rea$do +$ $+evo pro/e#to 2$droid

40
%$tor$o de desarrollo i$tegrado
Entorno "e Desarrollo
Para el entorno de desarrollo generado para extender cdigo en Android se
cuenta con un plugin o adaptador para un IDE
40
muy conocido, Eclipse
. .apt+ra de pa$talla del 7D% %#lipse #rea$do +$ $+evo pro/e#to 2$droid

$tor$o de desarrollo i$tegrado
49
generado para extender cdigo en Android se
muy conocido, Eclipse.

. .apt+ra de pa$talla del 7D% %#lipse #rea$do +$ $+evo pro/e#to 2$droid

Este plugin adapta y extiende funcionalidad para la creacin, d
funciones mencionadas:

Asistentes para la creacin rpida de
Complemento para crear interfaces grficas permitiendo el desarrollo de
componentes visuales.
Emulador personalizado de Android, el cual funciona sobre una terminal y
versin mvil virtual personalizable.
La interactividad e increment
como la toma de capturas de pantalla, depuracin en tiempo real,
redireccin de puertos, ver informacin de hilos de ejecucin en procesos,
etc.
Editores grficos para archivos XML que proporciona una mayor
comprensin y a sui vez desarrollo.
Figura

Este plugin adapta y extiende funcionalidad para la creacin, d

Asistentes para la creacin rpida de aplicaciones Android.
componentes visuales.
versin mvil virtual personalizable.
La interactividad e incrementos en funciones en herramientas de Android
comprensin y a sui vez desarrollo.
Figura6..apt+ra de pa$talla del %m+lador de 2$droid
50
Este plugin adapta y extiende funcionalidad para la creacin, depurado y otras
aplicaciones Android.
os en funciones en herramientas de Android

2.5 Seleccin de herramientas de almacenamientos de datos

Ya que la tecnologa que se us
Services es la tecnologa de Microsoft .NET, se pretende tambin utilizar dicha
tecnologa para la implementacin de soluciones de base de datos, ms
precisamente, SQL Server.

Microsoft SQL Server es un
datos de carcter relacional
soportadas son el transact SQL (T
El siguiente grafico [21]muestra

Figura

Las caractersticas de SQL SERVER 2008

Soporte de transacciones.
Escalabilidad, estabilidad

41
%s0+ema ,asado e$ la lgi#a de predi#ados / e$ la teora de #o$5+$tos.
42
Bomadas de :i>ipedia! ?ttp!OOes.wi>ipedia.orgOwi>iOMi#rosoftV*EIV*erver
Seleccin de herramientas de almacenamientos de datos
Ya que la tecnologa que se us para la generacin e implementacin de Web
precisamente, SQL Server.
es un gestor de base de datos basado en un modelo de
datos de carcter relacional
41
. El lenguaje de consultas y transacciones
soportadas son el transact SQL (T-SQL) y ANSI SQL.
muestra la estructura comercial de SQL SERVER 2008
Figura7. %s0+ema #omer#ial de *EI *%<4%< 2008
de SQL SERVER 2008 se detallan a continuacin
transacciones.
estabilidad y seguridad.

asado e$ la lgi#a de predi#ados / e$ la teora de #o$5+$tos.
?ttp!OOes.wi>ipedia.orgOwi>iOMi#rosoftV*EIV*erver
51
Seleccin de herramientas de almacenamientos de datos
para la generacin e implementacin de Web
or de base de datos basado en un modelo de
. El lenguaje de consultas y transacciones
SQL SERVER 2008.

se detallan a continuacin
42
:
52

Soporta procedimientos almacenados.
Incluye tambin un entorno grfico de administracin, que permite el uso
de comandos DDL y DML grficamente.
Permite trabajar en modo cliente-servidor, donde la informacin y datos se
alojan en el servidor y los terminales o clientes de lared slo acceden a la
informacin.
Adems permite administrar informacin de otros servidores de datos.

SQL Server 2008 permite almacenar datos de documentos estructurados, semi-
estructurados o no estructurados como es imgenes, msica y archivos
directamente dentro de la base de datos.
SQL Server 2008 facilita la obtencin de un mayor rendimiento de datos dotado
por servicios integrados como son consultas, sincronizaciones, bsquedas,
anlisis e informes.

Su principal ventaja dentro de este proyecto es la utilizacin del framework de
Microsoft para as, estimular la compatibilidad para desarrollar a medida en .NET
y Visual Studio desde su propia Arquitectura Orientada a Servicios (SOA). Esto se
debe a que este gestor de base de datos incluye interfaces de acceso para varias
plataformas de desarrollo, entre ellas y la principal .NET.

Su principal desventaja, como es de esperarse, es que necesita o requiere un
sistema operativo Microsoft Windows. Por ello, no puede instalarse en otros
sistemas y plataformas operativas.
Adems de esta desventaja, MSSQL no recurre a la comprensin de datos, por lo
que sus bases de datos pueden llegar a ocupar mucho espacio de
almacenamiento de disco..

53

CAPTULO III

3 MODELAMIENTO DEL SISTEMA

La descripcin analtica, lgica y el modelamiento del sistema es fundamental
para conseguir que los requerimientos tantos funcionales como no funcionales se
estructuren. Es as como validan de manera que se tenga consentimiento de
avance en el desarrollo del sistema y se haga una correcta administracin y
gestin de cambios.
El presente trabajo obtendr como resultado, una implementacin a modo de
prototipo, cumpliendo los requerimientos de inventario y conteo de stock
expresados por el cliente representado por la institucin CODEU.
Siguiendo con la metodologa que se aplicar
43
, centraremos todos los
requerimientos funcionales y no funcionales en la fase de exploracin de dicha
metodologa.
El objetivo de la fase de exploracin, como se haba mencionado, es la
planificacin y el establecimiento del presente proyecto de desarrollo. Esta fase es
de suma importancia para establecer las bases, la arquitectura, como tambin el
entorno donde operar el sistema. Asimismo, es necesario conocer y especificar
las distintas partes o grupos necesarios para la continuidad del proyecto.

Figura8. %tapas de la fase de %&plora#i$K22L

43
Mo,ile - D
54

3.1 Modelamiento del negocio

".1.1 #isin .eneral del Sistema

La visin del presente proyecto es desarrollar un sistema mvil para recuento de
stocks e inventarios, en el que se implemente Web Services para la transferencia
de informacin. Esto se har, administrndolo bajo una aplicacin web, a efecto
de maximizar el automatismo de los recursos en las empresas.

".1.2 *sta&lecimientode las partes interesadas /Sta0e1older
*sta&lis1ment2

El propsito de esta etapa es identificar y establecer los grupos de inters que son
necesarios en diversas tareas de la fase de exploracin, as como en actividades
de apoyo durante el desarrollo de software, excluyendo al equipo de desarrollo en
s.

3.1.2.1 0e/e "e Pro1ecto

Por las razones que conllevan la elaboracin del presente proyecto, esta
responsabilidad debe recaer en el Ing. Cesar Esquetini.

3.2 Modelamiento de requerimientos del sistema

Los requerimientos tanto funcionales como no funcionales se especificarn en la
etapa de Definicin del Alcance (Scope Definition) perteneciente a la fase de
exploracin de la metodologa utilizada.

El propsito de esta etapa es definir los objetivos para el proyecto incipiente en
relacin tanto en los contenidos, as como la lnea de tiempo del proyecto.Los
objetivos de la Definicin del Alcance son los siguientes:

55

Definicin de requerimientos iniciales, y
Definicin dela planificacin del proyecto.

".2.1 )efinicin de requerimientos iniciales /-nitial 3equirements Collection2

El propsito de esta tarea es producir una definicin general inicial de la del
alcance, propsito y funcionalidad del producto. Esto es necesario para la
planificacin y elestablecimiento del proyecto (tamao, detalles tcnicos,
arquitectura, etc.).

Adems, los requisitos documentados ser el punto de partida para construir una
visin de conjunto sobre el producto en cuestin. El cliente y el grupo de
direccin
44
deben estar de acuerdoy documentar la funcionalidad central del
producto como se ve desde el punto de vista del cliente. Adems, se consideran
otros requerimientos como los propios del negocio y la identificacin de
limitaciones para el desarrollo del producto, de acuerdosobre lo documentado. El
objetivo principal es identificar y acordar el alcance, la funcionalidad bsica y los
requisitos no funcionales ms relevantes para que el producto de software sea
desarrollado.

3.2.1.1 +e.uerimientos !uncionales

Administracin de usuarios

RF1. Creacin, modificacin e inactivacin de empleados, usuarios y roles
para diferentes accesos al sistema de administracin.
RF2. Creacin, asignacin y administracin de agrupaciones de usuarios para
facilitar su organizacin.

44
%spe#ifi#a#i$ e$ el rol.
56

Recoleccin de inventarios

RF3. Registrar el stock actual de libros por librera (sucursal) y enviarlo a un
servidor central.
RF4. Registrar el ingreso de libros por librera (sucursal) y enviarlo a un
servidor central.
RF5. Registrar la salida o venta de libros por librera (sucursal) y enviarlo a un
servidor central.
RF6. Registrar el traslado de libros de librera (sucursal) a otra y enviar dicha
transaccin a un servidor central.

Administracin de inventarios

RF7. Creacin, asignacin y administracin de categoras de libros para
facilitar su organizacin.
RF8. Creacin, asignacin y administracin de sucursales.
RF9. Generacin de reportes en tiempo real.
RF10. Exportacin de reportes a formato de MS Excel.
RF11. Generacin de un registro de log para cada transaccin que se
realice en el sistema.

Tabulacin de resultados

RF12. Una vez recolectados los stocks e inventarios de cada librera, el
sistema deber realizar la tabulacin de dichos de acuerdo a las
categoras, stock anterior y cuantificacin global.

Reportes

RF13. El sistema deber obtener reportes de los resultados de stock global,
ya sea por fechaso por libros.
RF14. El sistema deber obtener grficos acerca de las sucursales con
mayor audiencia y los libros con mayor flujo de venta.

57

3.2.1.2 +e.uerimientos 2o !uncionales

Los requerimientos no funcionales contemplan y especifican criterios en los que la
operacin de un sistemaes satisfactoria. A continuacin se detallan.

".2.1.2.1 3equerimientos de *quipos

Se deber contar con un servidor de Internet que permita la conexin de mltiples
usuarios hacia este.
Para que un usuario pueda acceder al servicio de registro de inventarios deber
tener una conexin a Internet a travs de su dispositivo mvil, este deber contar
con un sistema operativo Android mnimo versin 4.0.

".2.1.2.2 )isponi&ilidad

El sistema deber estar disponible durante las horas que los usuarios vayan a
utilizar el servicio.

".2.2 )efinicin de la planificacin del proyecto /-nitial !ro$ect !lanning2

El propsito de esta tarea es establecer el plan inicial para el desarrollo del
proyecto con respecto a la lnea de tiempo (calendario), el ritmo y las inversiones
del proyecto.Esto se hace con el fin de permitir el establecimiento posterior del
proyecto.Los objetivos de la planificacin inicial del proyecto son:

Establecer el cronograma del proyecto.
Estimar las inversiones necesarias para el proyecto (por ejemplo, el
esfuerzo y financiamiento).
Definir y asignar los recursos humanos necesarios para el desarrollo.
Definir y asignar los recursos tcnicos necesarios para el desarrollo.
Definir y asignar los recursos relacionados con el medio ambiente de
58

trabajo necesario para el desarrollo.

3.2.2.1 -ronograma "el #ro1ecto

Figura9. .ro$ograma del pro/e#to por etapas metodolgi#as.

Figura10. .ro$ograma de la etapa de prod+#ti8a#i$.
59

Figura11. .ro$ograma de la etapa de prod+#ti8a#i$ para el *tor/#ard MIogi$ de Cs+ariosN

3.2.2.2 )nlisis "e -ostos

El costo de esta propuesta incluida la implementacin de un prototipo se la realiza
en base al tiempo estimado en cronograma, 9 meses, y la inversin de equipos
incluidos los dispositivos mviles con los cuales se operaria. Se toma en cuenta el
los recursos humanos que desarrollarn, planificarn y probarn la solucin;
tambin se incluye las licencias del software que se utilizaran como herramientas.

Para realizar la estimacin del licenciamiento no se tomar en cuenta el SW libre
o no propietario que se utilizar en este proyecto, adems del SW propietario se
utilizar, como se indic anteriormente, productos Microsoft de los cuales existen
versiones Express en los cuales sus licencias no tienen costo.

El anlisis de costos para el equipo de trabajo y desarrollo del prototipo se vern
desglosados de la siguiente manera:
Rol Meses Personas Costo Mensual Costo Total
Lder del Proyecto 9 1 1000
$ 9.000,00
Desarrollador 9 1 800
$ 7.200,00
Testing 2 1 600
$ 1.200,00
TOTAL
$ 17.400,00
Tabla 5. .ostos por miem,ro del %0+ipo
60

Adems de los costos antes mencionados se tomar en cuenta los equipos en los
cuales se probar la aplicacin mvil. Esto sugiere un total de cuatro equipos, dos
smartphones y dos tabletas, estas debern tener acceso a Internet a travs de la
red 3g de datos que se les proporcione por medio de una operadora telefnica.

ITEM Cantidad Valor Unitario Costo Total
Smartphones 2
$ 250,00 $ 500,00
Tablets 2
$ 360,00 $ 720,00
TOTAL
$ 1.220,00
Tabla 6. .ostos por dispositivos mviles

Los costos tanto de inversin en equipos como para el desarrollo del sistema se
muestran a continuacin:

ITEM Costo Total
Inversin en Equipos
$ 1.220,00
Desarrollo del Sistema
$ 17.400,00
Paquete de datos
45

$ 360,00
TOTAL
$ 18.980,00
Tabla 7. .ostos total del pro/e#to

El costo del desarrollo del sistema es de $ 18.980 incluyendo el primer ao del
paquete de datos. Lo que hace que el sistema relativamente sea mucho ms barato que
otros sistemas que ofrecen un servicio automatizado de toma de inventarios.

3.2.2.3 +ecursos 3umanos

Se describirn los roles, responsabilidades y los recursos humanos implicados en
la siguiente tabla.

45
Barifa vige$te refere$#ia de Movistar a 5+lio de 2013
61

Rol Responsabilidad Recurso Humano
Jefe de Proyecto Cuenta con habilidades de gestin
de proyectos y conduce un
proyecto desde su inicio hasta su
lanzamiento.
Como se ha indicado a
lo largo de este proyecto
y por las razones que
conllevan esta
responsabilidad, recae
sobre el Ing. Cesar
Esquetini.
Programador Escribe las pruebas unitarias y
produce el cdigo del sistema.
Este trabajo recae sobre
el autor, es decir, el
seor Irwin Ortiz
Testing Ejecuta las pruebas que escribe el
programador, difunde los
resultados al equipo y es el
responsable de soporte para
pruebas.
Asimismo por la
naturaleza de la
realizacin del proyecto,
recae sobre el seor
Irwin Ortiz
Cliente Proporciona la informacin para el
asentamiento de requerimientos
funcionales como no funcionales y
estima la implementacin para el
prototipo desarrollado.
La responsabilidad cae
sobre la representacin
de la empresa CODEU,
es decir el Lcdo.
Edmundo Batallas
Tabla 8. <oles / <espo$sa,ilidades

3.3 Modelamiento del anlisis y diseo del sistema

El modelamiento ayudar a definir una lnea de arquitectura para el proyecto bajo
metodologa Mobile-D.Los problemas de arquitectura y las fuentes potenciales de
riesgosarquitectnicos, deben ser explorados.As por ejemplo, el contexto del
sistema, las plataformas de software, las abstracciones bsicas posibles, los
conductores que conforman la arquitectura del sistema que est siendo
construida, la calidad del producto interno, la documentacin de arquitectura de
software y diseo en los documentos finales del proyecto, y las habilidades

arquitectnicas necesarias.

".".1 An'lisis del Sistema

3.3.1.1 )nlisis "e Procesos "el sistema

Se adjuntan los diagramas BPMN
sistema, cabe recalcar que dichos procesos han sido basados en
requerimientos funcionales
continuacin diagramas de procesos de negocio en notacin BPMN
Usuarios

1. Login de usuarios

Figura

arquitectnicas necesarias.
An'lisis del Sistema
)nlisis "e Procesos "el sistema
e adjuntan los diagramas BPMN 2.0 correspondientes a cada proceso en el
sistema, cabe recalcar que dichos procesos han sido basados en
requerimientos funcionales denotados en la seccin 3.2.1.1.
continuacin diagramas de procesos de negocio en notacin BPMN
de usuarios.
Figura12. "ro#eso 3"M para Iogi$ de +s+arios

62
correspondientes a cada proceso en el
sistema, cabe recalcar que dichos procesos han sido basados en los
. Se presentar a
continuacin diagramas de procesos de negocio en notacin BPMN 2.0

2. Gestin de usuarios

Figura
3. Gestin de roles.

Figura

Gestin de usuarios.
Figura13. "ro#eso 3"M para =esti$ de Cs+arios
Gestin de roles.
Figura14. "ro#eso 3"M para =esti$ de <oles

63

4. Gestin de agrupacin de usuarios.

Figura15. "ro#eso 3"M para gesti$ de 2gr+pa#i$ de Cs+arios

Inventarios por sucursal

5. Registrar el stock actual

Figura

Gestin de agrupacin de usuarios.
. "ro#eso 3"M para gesti$ de 2gr+pa#i$ de Cs+arios
por sucursal
Registrar el stock actual.
Figura16. "ro#eso 3"M para <egistrar *to#>

64

. "ro#eso 3"M para gesti$ de 2gr+pa#i$ de Cs+arios

6. Registrar venta

Figura

7. Registrar traslado

Figura

Registrar venta.
Figura 17. "ro#eso 3"M para <egistrar 4e$ta
Registrar traslado.
Figura 18. "ro#eso 3"M para <egistro Braslado
65

8. Consultar libro existente

Figura 19


9. Gestin de categoras

Figura

libro existente en otra sucursal.
19. "ro#eso 3"M para .o$s+lta de Ii,ro e$ otra *+#+rsal
categorasde libros.
Figura 20. "ro#eso 3"M para =esti$ .ategora de li,ros

66

. "ro#eso 3"M para .o$s+lta de Ii,ro e$ otra *+#+rsal

10. Gestin de sucursales

Figura

Reportes

11. Gestin de

Figura

sucursales.
Figura 21. "ro#eso 3"M para =esti$ de *+#+rsales
Gestin de reportes.
Figura 22. "ro#eso 3"M para =esti$ de <eportes

67

12. Generacin de reportes

Figura

13. Exportar a

Figura

Generacin de reportes.
Figura 23. "ro#eso 3"M para =e$era#i$ de <eportes
Exportar a diversos formatos.
Figura 24. "ro#eso 3"M para %&portar a diversos formatos

68

14. Generacin de grficos estadsticos

Figura 25. "ro#eso 3"M para =e$era#i$ de =r
3.3.1.2 4ar*etas "e 3istorias "e 5suario (

El propsito de esta labor es generar el calendario y el contenido de la iteracin
para ejecutar. Los contenidos se definen en trminos de tareas que son rdenes
de trabajo para el equipo
El objetivo de la planificacin de la iteracin es:
1. Transformar las historias en un conjunto de tareas sin ambigedades y
bien definido.
".".1.2.1 4ogin de usuarios
Nmero / ID Tipo
Antes
01
Nuevo Fcil
Fijo Moderado
Mejora Duro
Descripcin

Para iniciar sesin en el dispositivo
logueado antes se comprobar si los datos de logueo son los mismo o se han mantenido caso contrario se
deber ingresar los datos de logueo para su respectiva verificacin.
mensajes del usuario si tiene alguna peticin de libros para el traspaso de otra sucursal.

Fecha Estado
lun 1!0"!11 Definido
jue 1!0"!1# $mplementado
vie 1!0"!1% &echo
mar 1!0"!1' (erificado
!
Pospuesto ) *ancelado )
*omparado
Generacin de grficos estadsticos.
. "ro#eso 3"M para =e$era#i$ de =rfi#os %stadsti#os

3istorias "e 5suario (Stor1car"s)
de trabajo para el equipo.
El objetivo de la planificacin de la iteracin es:
ansformar las historias en un conjunto de tareas sin ambigedades y

4ogin de usuarios.
Dificultad Esfuerzo
Prioridad
es Despu+s ,stimado ,mpleado
Fcil Fcil
# %
-aja
Moderado Moderado Media
Duro Duro Alta
en el dispositivo mvil. el usuario deber ingresar el usuario / la
deber ingresar los datos de logueo para su respectiva verificacin. Adems se deber buscar en el
lguna peticin de libros para el traspaso de otra sucursal.
omentario


Storycard 1. Iogi$ de +s+arios
69

fi#os %stadsti#os
ansformar las historias en un conjunto de tareas sin ambigedades y
Prioridad Notas

la contrase0a. 1i este se ha
se deber buscar en el bu2n de

70

".".1.2.2 .estin de usuarios.
Nmero / ID Tipo
Dificultad Esfuerzo
Prioridad Notas
Antes Despu+s ,stimado ,mpleado
0
Nuevo Fcil Fcil

-aja

Fijo Moderado Moderado Media
Mejora Duro Duro !lta
Descripcin

,3iste un usuario no t+cnico 4vendedor de sucursal5 / un administrador del sistema. desde el momento de la
instalacin. ,l administrador ingresa los datos de un nuevo usuario con untipo de usuario o tambi+n llamado rol /
de ser el caso una agrupacin de usuarios. 6a informacin a ingresar inclu/e nombre. usuario. contrase0a. fecha
de registro. / numero celular. 1e debe controlar todos los usuarios 7ue ingresan al sistema / tambi+n se da la
opcin de modificacin / eliminacin de usuarios no activos. en todos sus valores de informacin e3cepto en su
fecha de registro.

Fecha Estado omentario
jue 1!0"!1 Definido

mar 1!0"!" $mplementado

mar 1!0"!1' &echo

vie 1!0"!' (erificado

!
*omparado
Storycard 2. =esti$ de +s+arios
".".1.2." .estin de roles.
Nmero / ID Tipo
Dificultad Esfuerzo
Prioridad Notas
08
Nuevo Fcil Fcil

-aja

Mejora Duro Duro Alta
Descripcin

Para la administracin / operacin del sistema se consideraran 8 tipos de usuario9Administrador. ,jecutivo
/(endedor.Administrador9 ,s el :nico acreditado para la creacin. modificacin / eliminacin de usuarios /
roles 4inclu/e asignacin de grupos5. gestin de sucursales. etc. ,ste usuario pertenece a la categor;a de rol
<=eb>.,jecutivo9 ,s el usuario 7ue solo tiene acceso a reporter;a de inventario / datos de grficos estad;sticos.
,ste perfil es definido por el administrador / pertenece a la categor;a de rol <=eb>.(endedor9 ,s el :nico 7ue
accede al sistema mediante dispositivos mviles en sucursal. ,ste usuario puede registrar stoc?s. libros.
devoluciones. ventas. env;o de mensajes de peticin de libros a sucursales 7ue contengan el stoc?. etc.
Pertenece a la categor;a de rol <mvil>.
mar 1!0@!08 Definido

vie 1!0@!0" $mplementado

lun 1!0@!0' &echo

mi+ 1!0@!11 (erificado

!
*omparado
Storycard 3. =esti$ de roles
71

".".1.2.% .estin de agrupacin de usuarios.
Nmero / ID Tipo
Dificultad Esfuerzo
Prioridad Notas
0#
Auevo Fcil Fcil

"a#a

Fi#o Moderado Moderado Media
Descripcin

6os usuarios se podrn agrupar por grupos perfectamente marcado por ubicacin geogrfica. propiamente
dicho. por sucursal. ,sta opcin de agrupacin solo se deber aplicar a los usuarios del grupo <mvil>. es decir.
solo es aplicable a los usuarios 7ue tienen acceso al sistema a trav+s de dispositivos mviles ubicados en diversas
sucursales. ,sta funcionalidad servir para agrupar a los usuarios 7ue se encuentran dentro de una misma
sucursal. sobre todo para el env;o / la recepcin de mensajes de solicitud de libros entre sucursales.

vie 1!0@!18 Definido

mi+ 1!0@!1B $mplementado

jue 1!0@!1' &echo

lun 1!0@!8 (erificado

!
*omparado
Storycard 4. =esti$ de agr+pa#i$ de +s+arios
".".1.2.5 3egistrar stoc0 actual.
Nmero / ID Tipo
Dificultad Esfuerzo
Prioridad Notas
0%
Nuevo Fcil Fcil

-aja

Descripcin

Para el correcto registro de libros 7ue contengan las sucursales / adems ingresos posteriores a los registros de
stoc? iniciales. se contar con el registro automtico de stoc? de libros por lectura de cdigo de barras. Cna ve2
7ue el proceso ha comen2ado. se escanear el cdigo de barras)cdigo DE del libro a registrar usando la
cmara del dispositivo mvil donde se tenga instalado el aplicativo mvil nativo android. una ve2 escaneada e
interpretada se validar si los datos asociados del libro /a e3isten en el sistema. 1i estos no e3isten se proceder
a registrar los datos del mismoF si e3iste el registro del libro. se registrar a dicho libro en el stoc? de la sucursal
donde el usuario est registrando el libro.

mi+ 1!0@!% Definido

lun 1!0@!80 $mplementado

mar 1!0@!81 &echo

jue 1!0B!0 (erificado

!
*omparado
Storycard 5. <egistrar sto#> a#t+al
72

".".1.2.6 3egistrar venta.
Nmero / ID Tipo
Dificultad Esfuerzo
Prioridad Notas
0"
Nuevo Fcil Fcil

-aja

Descripcin

1e registrar la venta a efecto de registro de inventario para la actuali2acin / disminucin de stoc?. Para
registrar dicha venta. el usuario en sucursal proceder a escanear el cdigo de barras del libro a vender. se
proceder a efectuar la comprobacin del libro mediante los datos asociados a este.Cna ve2 confirmada la
venta se la contabili2a / se procede a actuali2ar los registros de stoc? de la sucursal donde fue vendido el libro.

lun 1!0B!0" Definido

jue 1!0B!0' $mplementado

vie 1!0B!10 &echo

mar 1!0B!1# (erificado

!
*omparado
Storycard 6. <egistrar ve$ta
".".1.2.7 3egistrar traslado.
Nmero / ID Tipo
Dificultad Esfuerzo
Prioridad Notas
0B
Nuevo Fcil Fcil

-aja

Descripcin

Para registrar el traslado de libros de una sucursal a otra debe e3istir anteriormente el mensaje de peticin de
libros por parte de la sucursal solicitante de stoc?. ,sta a su ve2. enviar este mensaje de peticin a la sucursal
7ue anteriormente el sistema ha/a indicado 7ue cuenta con el libro / el registro de traslado se lo reali2ar en la
sucursal solicitante de libro. Cna ve2 se ha/a confirmado el traslado se contabili2ar el libro en el stoc? de la
nueva sucursal / se lo eliminara en el stoc? de la sucursal 7ue lo env;a.

mar 1!0B!B Definido

mar 1!0B!1 $mplementado

mi+ 1!0B! &echo

vie 1!0B!# (erificado

!
*omparado
Storycard 7. <egistrar traslado

73

".".1.2.8 Consultar li&ro e9istente en otra sucursal.
Nmero / ID Tipo
Dificultad Esfuerzo
Prioridad Notas
0'
Auevo Fcil Fcil

-aja

Me#ora Duro Duro !lta
Descripcin

*uando en una sucursal no e3ista en stoc? un libro 7ue se necesitara. se deber enviar un respectivo mensaje
de peticin a alguna sucursal 7ue lo contenga. Para saber si e3iste alguna sucursal 7ue contenga el libro
solicitar se deber reali2ar una b:s7ueda de dicho material en las diferentes sucursales. Para lo 7ue se estimar
para la b:s7ueda el nombre. autor /)o descripcin del libro a solicitar. Cna ve2 consultado si el libro e3iste en
alguna sucursal se reali2ara la peticin del libro por parte de la sucursal solicitante mediante un mensaje 7ue lo
recibir cual7uier usuario 7ue pertene2ca al grupo de dicha sucursal a la cual se le env;a el mensaje. 6as
comprobaciones de mensajes nuevos se las reali2ar cada ve2 7ue el usuario se identifi7ue en la aplicacin
mvil.
vie 1!0'!0@ Definido

mi+ 1!0'!1 $mplementado

jue 1!0'!18 &echo

lun 1!0'!1@ (erificado

!
*omparado
Storycard 8. .o$s+ltar li,ro e&iste$te e$ otra s+#+rsal
".".1.2.: .estin de categoras de li&ros.
Nmero / ID Tipo Dificultad Esfuerzo Prioridad Notas
10
Nuevo Fcil Fcil

"a#a

Descripcin

Para el correcto funcionamiento / operacin del sistema / sobretodo un acceso a libros gilmente se ha
establecido 7ue un libro tenga categor;as. 6a gestin de categor;as de libros proceder a crear. modificar / si es
necesario a eliminar las categor;as 7ue podr;a pertenecer un libro. 1olo los usuarios con el rol del tipo
<Administrador> podr;an hacer esta tarea desde el portal de configuracin del sistema.

mi+ 1!0'!1' Definido

lun 1!0'!# $mplementado

mar 1!0'!% &echo

jue 1!0'!@ (erificado

!
*omparado
Storycard 9. =esti$ de #ategoras de li,ros
74

".".1.2.1; .estin de sucursales.
11
Nuevo Fcil Fcil

"a#a

Descripcin

Para el correcto funcionamiento / operacin del sistema / sobretodo un gestin basada en geo locali2acin en
el futuro se ha establecido la gestin de sucursales. ,n la funcionalidad de dicha gestin se proceder a crear.
modificar / si es necesario a eliminar sucursales para la correcta distribucin de libros. mensaje de peticin de
otras sucursales / registro de stoc? 7ue podr;a tener. 1olo los usuarios con el rol del tipo <Administrador> podr;an
hacer esta tarea desde el portal de configuracin del sistema.

lun 1!10!01 Definido

jue 1!10!0# $mplementado

vie 1!10!0% &echo

mar 1!10!0' (erificado

!
*omparado
Storycard 10. =esti$ de s+#+rsales
".".1.2.11 .estin de reportes.
1
Nuevo Fcil Fcil

"a#a

Descripcin

6a gestin de reportes est ligada al guardado / eliminacin de un reporte 7ue el usuario ha/a mostrado /
generado obligatoriamente en cierto momento. ,sta gestin ser a nivel de archivos dentro del sistema
operativo del servidor donde se publicarn para su muestra.
1olo los usuarios con el rol del tipo <,jecutivo> podr;an hacer esta tarea desde el portal de muestra de datos
estad;sticos / reportes del inventario.

jue 1!10!11 Definido

mar 1!10!1" $mplementado

mi+ 1!10!1@ &echo

vie 1!10!1' (erificado

!
*omparado
Storycard 11. =esti$ de reportes

75

".".1.2.12 .eneracin de reportes.
18
Nuevo Fcil Fcil

-aja

Descripcin

6a generacin de reportes como tema de anlisis de la informacin de inventarios recogidos por los diversos
usuarios en dispositivos mviles. estos se actuali2arn automticamente para su anlisis. ,stos reportes incluirn
informacin de stoc?. sucursales. libros. usuarios. etc
estad;sticos / reportes del inventario. ,stos sern capaces de generar reportes pre configurados para la
visuali2acin de la informacin.

mar 1!10!8 Definido

vie 1!10!" $mplementado

lun 1!10!' &echo

mi+ 1!10!81 (erificado

!
*omparado
Storycard 12. =e$era#i$ de reportes
".".1.2.1" *9portar a diversos formatos.
1#
Nuevo Fcil Fcil

"a#a

Descripcin

6a opcin de e3portacin a diversos formatos del reporte generado deber presentarse al momento de la
generacin de reporte en el portal de muestra de datos estad;sticos / reportes del inventario. ,sto con fines
ligados al manejo de datos con otros productos de terceros para su anlisis.

vie 1!11!0 Definido

mi+ 1!11!0@ $mplementado

jue 1!11!0B &echo

lun 1!11!1 (erificado

!
*omparado
Storycard 13. %&portar a diversos formatos
76

".".1.2.1% .eneracin de gr'ficos estadsticos.
1%
Nuevo Fcil Fcil

"a#a

Descripcin

6a generacin de grficos estad;sticos se incluir en el anlisis de la informacin de reportes como un plus
dentro del anlisis estad;stico oportuno 7ue incluir informacin representada grficamente de sucursales.
ventas. stoc?. libros. usuarios. roles. etc. ,sta opcin deber presentarse al momento de la generacin de
reporte en el portal de muestra de datos estad;sticos / reportes del inventario.
1olo los usuarios con el rol del tipo <,jecutivo> podr;an ver dichos grficos desde el portal de muestra de datos

mi+ 1!11!1# Definido

lun 1!11!1' $mplementado

mar 1!11!0 &echo

jue 1!11! (erificado

!
*omparado
Storycard 14. =e$era#i$ de grfi#os estadsti#os
".".1.2.15 Seguridad.
1"
Nuevo Fcil Fcil

"a#a

Descripcin

,l sistema debe tener patrones de seguridad teniendo en cuenta lasdiferentes plataformas en la 7ue sentar el
sistema total. 6a :nica forma de ingreso al sistema debe ser por la autenticacin de los usuarios sea en los
dispositivos mviles ubicados en las sucursales por usuario o en el portal de reporter;a / datos estad;sticos.
,l acceso de un usuario debe considerarse de forma e3clusiva. es decir 7ue si un usuario ingresa al sistema. no se
podr permitir acceder a otro usuario con el mismo nombre. Debe e3istir inviolabilidad de informacin de la
base de datos.

lun 1!11!" Definido

jue 1!11!' $mplementado

vie 1!11!80 &echo

mar 1!1!0# (erificado

!
*omparado
Storycard 15. *eg+ridad
77

3.3.1.3 4areas #or $teracin

78

Figura 26. Bareas por 7tera#i$ / por 7terar

3.3.1.' 4ar*etas "e 4areas (4as6-ar"s)

Las tarjetas de tareas por Historia de Usuario servirn para ejecutar rdenes de
trabajo para el equipo de desarrollo y adems, servirn para estimar un calendario
con la posible programacin de tareas. A continuacin, se describen las tarjetas
de tareas desglosadas para las historias de usuarios anteriormente descritas.

79

".".1.%.1 !o&lar ase de )atos con parametri<acin inicial.
Nmero / ID
Tipo
Dificultad onfianza Duracin

Antes Despu+s
1 4poco confian2a5
Estimado Empleado
1
# 4mucha confian2a5
Auevo Fcil Fcil

Fijo Moderado Moderado
Mejora Duro Duro

Descripcin
6a empresa *GD,C ha proporcionado un archivo de M1 ,3cel con la informacin de inventarios actual en la cual se encuentra
la informacin relacionada al stoc? de libros 7ue e3iste / los tipos de categor;a de libros 7ue e3iste / la informacin de stoc? de
sucursales. De esta manera esta tarea consistir en9
1. *rear el script de la base de datos relacional dise0ada anteriormente.
. *rear todos los componentes a nivel de base de datos.
8. *rear un script con la informacin del archivo ,3cel para la carga de informacin inicial relacionada a libro.
categor;a de libro / stoc? de sucursales.

Definido

$mplementado

&echo

(erificado

Pospuesto ) *ancelado ) *omparado

TASKCAR1. "o,lar 3ase de Datos #o$ parametri8a#i$ i$i#ial.
".".1.%.2 *la&oracin de Clases e -nterfaces para 4ogin de usuarios en Servidor
Central.
Nmero / ID
Tipo

Antes Despu+s
1 4poco confian2a5
Estimado Empleado

# 4mucha confian2a5
Auevo Fcil Fcil

Mejora Duro Duro

Descripcin
Cna ve2 cargada la informacin perteneciente a la base de datos relacional. se hace el respectivo anlisis. dise0o e
implementacin de clases e interfaces relacionadas a cada entidad con el fin de atomi2ar e ir granulando la estructura del
sistema dentro del servidor central. ,stas clases / a su ve2 los objetos clases implementados. es decir. sus interfaces servirn para
el establecimiento de los servicios =eb a crearse para el consumo de apiHs propias creadas para la aplicacin general. De esta
manera esta tarea consistir en9
1. Anali2ar / dise0ar un bos7uejo de 7ue entidades servirn activamente para la construccin de las clases e interfaces
necesarias.
. $mplementar el anlisis / dise0o anterior considerando atributos. tipos de datos / nomenclaturas.


Definido

$mplementado

&echo

(erificado


TASKCAR2. %la,ora#i$ de .lases e 7$terfa#es para Iogi$ de +s+arios e$ *ervidor .e$tral.
80

".".1.%." *la&oracin y !u&licacin de +e& Service/s2 para 4ogin de =suarios.
Nmero / ID
Tipo

Antes Despu+s
1 4poco confian2a5
Estimado Empleado
8
# 4mucha confian2a5
Auevo Fcil Fcil

Mejora Duro Duro

Descripcin
,sta tarea consistir en la creacin. implementacin / pruebas de conectividad de los Ieb 1ervices creados sobre el servidor
central. adems se prever / se contemplar la planificacin de Ieb 1ervices descritos en los diagramas de negocio 4-PMA5
para su correcta interpretacin. De esta manera esta tarea consistir en9
1. Anali2ar / e3traer de los diagramas de negocio informacin referente al anlisis / dise0o de los diferentes Ieb
1ervices para la construccin de la intercomunicacin con las diferentes plataformas para el sistema.
. $mplementar los Ieb 1ervices considerando atributos. tipos de datos / nomenclaturas.

Definido

$mplementado

&echo

(erificado


TASKCAR3. %la,ora#i$ / "+,li#a#i$ de :e, *ervi#e's) para Iogi$ de Cs+arios.
".".1.%.% )ise>o de -nterfa< de =suario en App Mvil para 4ogin de =suarios.
Nmero / ID
Tipo

Antes Despu+s
1 4poco confian2a5
Estimado Empleado
#
# 4mucha confian2a5
Auevo Fcil Fcil

Mejora Duro Duro

Descripcin
,sta tarea consistir en la creacin de prototipos de la interfa2 para decidir las caracter;sticas. organi2acin. apariencia /
funcionamiento de la interfa2 del usuario.,l dise0o de la interfa2 se reali2ara de forma incremental. De esta manera esta tarea
consistir en9
1. Anali2ar / comprender las tareas 7ue reali2a el usuario / su entorno de trabajo.
. Prototipar la interfa2 de usuario. es decir. dar un dise0o base sobre la 7ue estarn determinadas futuras iteraciones.
8. 1e evaluara por medio de pruebas la e3periencia real del usuario.

Definido

$mplementado

&echo

(erificado


TASKCAR4. DiseDo de 7$terfa8 de Cs+ario e$ 2pp Mvil para Iogi$ de Cs+arios.
81

".".1.%.5 *la&oracin de Clases e -nterfaces para Consumo de +e& Services para 4ogin
de =suarios en dispositivo mvil.
Nmero / ID
Tipo

Antes Despu+s
1 4poco confian2a5
Estimado Empleado
%
# 4mucha confian2a5
Auevo Fcil Fcil

Mejora Duro Duro

Descripcin
,sta tarea espec;fica la elaboracin de la estructura de consumo de Ieb 1ervices 7ue tendremos en el dise0o del dispositivo
mvil de manera 7ue tanto la generacin como el consumo de Ieb 1ervices contenga una estructura lgica / este
conformada por una granularidad de forma 7ue la implementacin sea rpida a trav+s del anlisis / el dise0o de clases e
interfaces para el consumo. De esta manera esta tarea consistir en9
1. Anali2ar / dise0ar un bos7uejo de 7ue entidades servirn activamente para la construccin de las clases e interfaces
necesarias para el consumo de Ieb 1ervices.
. $mplementar el anlisis / dise0o anterior considerando atributos. tipos de datos / nomenclaturas.

Definido

$mplementado

&echo

(erificado


TASKCAR5. %la,ora#i$ de .lases e 7$terfa#es para .o$s+mo de :e, *ervi#es para Iogi$ de
Cs+arios e$ dispositivo mvil.
".".1.%.6 3equerimientos ,o ?uncionales para 4ogin de =suarios.
Nmero / ID
Tipo

Antes Despu+s
1 4poco confian2a5
Estimado Empleado
"
# 4mucha confian2a5
Auevo Fcil Fcil

Mejora Duro Duro

Descripcin
1e considerarn los mismos re7uerimientos no funcionales para el sistema en general. es decir9
1. 1e deber contar con un servidor de $nternet 7ue permita la cone3in de m:ltiples usuarios hacia este.
. Para 7ue un usuario pueda acceder al servicio de registro de inventarios deber tener una cone3in a $nternet a
trav+s de su dispositivo mvil. este deber contar con un sistema operativo Android m;nimo versin #.0.
Ee7uerimientos de Disponibilidad9
8. ,l sistema deber estar disponible durante las horas 7ue los usuarios va/an a utili2ar el servicio.

Definido

$mplementado

&echo

(erificado


Ta!"card 6. <e0+erimie$tos ;o 6+$#io$ales para Iogi$ de Cs+arios.
82

".".1.%.7 Creacin de Aplicacin +e& 4igera.

Nmero / ID
Tipo

Antes Despu+s
1 4poco confian2a5
Estimado Empleado
@
# 4mucha confian2a5
Auevo Fcil Fcil

Mejora Duro Duro

Descripcin

,sta tarea consistir en la creacin de la aplicacin =eb ligera mediante la utilidad de Microsoft (isual 1tudio.
Microsoft 6ight 1=itch para la administracin del sistema. tablas. parmetros. / dems acceso administrativo
dentro de los diferentes roles 7ue administraran usuarios. categor;as. tablas catlogos. etc.
,sta tarea consistir en9
1. *reacin mediante asistentes rpidos de la aplicacin base para administrador de datos conectados
directamente a la base de datos del servidor central del sistema.
. ,stablecer seguridades para la aplicacin concebida.
8. Publicacin de la aplicacin en el servidor $$1


Definido

$mplementado

&echo

(erificado

*omparado
Ta!"card 7. .rea#i$ de 2pli#a#i$ :e, Iigera.

".".2 )ise>o del Sistema

El propsito de esta tarea es preparar a todos los problemas de arquitectura
crticos para que todos estn en plena disposicin. De esta manera, se logra un
crecimiento arquitectnico sistemticoen la aplicacin de los requisitos
determinados por el cliente en las anteriores fases del proyecto.

3.3.2.1 $n/raestructura1 )r.uitectura

Figura

3.3.2.2 Primera $nteraccin

Conjuntamente con las primeras definiciones como
y dems, el objetivo de la primera iteracin fue el de
sistema as como la infraestructura. Adems, se usaron
tecnolgicas para su desarrollo

3.3.2.3 Segun"a $nteraccin

La segunda iteracin consisti en la definicin de un modelo de datos y negocio
BPM de negocio, en el c
mvil y su captura de datos. Tambin se consigui capturar, transformar y cargar
datos reales pertenecientes a la empresa CODEU en a base de datos relacional
1 )r.uitectura "el Sistema
Figura 27.7$fraestr+#t+ra Be#$olgi#a del *istema
Primera $nteraccin
Conjuntamente con las primeras definiciones como la gestin de Usuarios,
dems, el objetivo de la primera iteracin fue el de instituir la arquitectura del
as como la infraestructura. Adems, se usaron
para su desarrollo.
Segun"a $nteraccin
consisti en la definicin de un modelo de datos y negocio
BPM de negocio, en el cual se muestran todo el negocio que contar la aplicacin
datos reales pertenecientes a la empresa CODEU en a base de datos relacional
83

la gestin de Usuarios, Roles
instituir la arquitectura del
as como la infraestructura. Adems, se usaron herramientas
consisti en la definicin de un modelo de datos y negocio
ual se muestran todo el negocio que contar la aplicacin
datos reales pertenecientes a la empresa CODEU en a base de datos relacional.
84

3.3.2.' 4ercera $nteraccin

Con esta iteracin se hizo pruebas de concepto, se termin de gestionar todas las
clases, entidades e interfaces as como de los Web Services que utilizaremos y
consumiremos en la aplicacin mvil. Se configurel servidor central en casa de
Irwin Ortiz para su acceso tanto de lectura como escritura en base de datos, su
conectividad desde la web, y se valid el comportamiento de los Web Services
publicados para su consumo.

3.3.2.( -uarta $nteraccin

Se desarroll las clases, interfaces y Web Services restantes para la funcionalidad
de la aplicacin. Tambin se disearon interfaces de usuario y apariencia para el
dispositivo mvil.

3.3.2.7 8uinta $nteraccin

Se implement y se valid la comunicacin global del sistema, se termin el
desarrollo de la aplicacin mvil y se desarroll tambin la aplicacin Web de
administracin y reportes.

3.3.2.9 Sexta $nteraccin

Siendo la ltima iteracin, se prob los ltimos detalles para la entrega final del
sistema.

85

"."." ,omenclaturas

3.3.3.1 2ombre "e Enti"a"es

Para el caso de las tablas de la base de datos se utilizar el nombre escrito en
letras minsculas. El nombre de la tabla estar asociado al sustantivo al que hace
referencia; si son varias palabras se debe de intercalar entre maysculas y
minsculas, este mecanismo de nombre es llamado camelCase
46
, ver Tabla 6

Objeto Descripcin Ejemplo
Tabla Tabla que almacena la informacin de los usuarios del sistema usuario
Tabla
Tabla que almacena la informacin de las categoras de libros
que estarn registrados en el sistema
categoriaLibro
Tabla9. %st$dar de $ome$#lat+ra F Ba,las

El nombre para las columnas empezara con un sustantivo tambin que
representar el atributo seguido con el nombre de la tabla cuya primera letra se
escribir en maysculas. El nombre escogido para la columna debe hacer
referencia al tipo de informacin que almacenar, ver la tabla 7

Objeto Descripcin Ejemplo
Nombre de la
columna
Campo que almacena el nombre del libro en el
sistema. Tabla Libro
nombreLibro
Nombre de la
columna
Campo que almacena el cdigo de cliente en el
sistema. Tabla Cliente
idCliente
Tabla10. %st$dar de $ome$#lat+ra F2tri,+tos

Las convenciones de cdigo definen el estndar de uso de nombres para las
diferentes tipificaciones usadas en el momento del desarrollo. Las
recomendaciones basadas en las mejores prcticas de Sun en las cuales se
desarrollar son:

46
Csado por *+$ Mi#ros/stems para $ome$#lat+ra @ava
86

".".".1.1 Clases

Para todo nombre de clase, la primera letra debe de ser Mayscula. Si son
varias palabras se debe de intercalar entre maysculas y minsculas. Este
mecanismo mencionado anteriormente es llamado camelCase.

".".".1.2 M@todos

Para los mtodos de clases, la primera letra debe ser minscula. Si son
varias palabras, se debe de intercalar entre minsculas y maysculas. Para
el caso de los mtodos de clases aplica el mecanismo del camelCase.

".".".1." #aria&les

Para las variables, se aplica el caso de los mtodos de camelCase. Es
importante de destacar que los nombres de las variables, adems de
cumplir lo anterior, deben ser cortos y descriptivos en s mismo.

".".".1.% Constantes

Para las constantes, su nombre deber ser escrito completamente en
Maysculas, y para la separacin de palabras se debe usar el
underscore/guin bajo (_). (Por ejemplo MAX_SUMA, VALOR_MULTIPLO).

".".".1.5 Otros o&$etos

Se establecer como norma el uso de la nomenclatura camelCase a
excepcin de ciertos casosevidentes.

".".% Modelo de datos

87

3.3.'.1 Mo"elo Enti"a" : +elacin

Figura 28.Modelo %$tidad - <ela#i$
88

3.3.'.2 Diccionario "e Datos

Name Code Parent Generate
categoriaLibro CATEGORIALIBRO Conceptual Data Model
'ConceptualDataModel_CodeuInventario'
TRUE
categoriarol CATEGORIAROL Conceptual Data Model
TRUE
cliente CLIENTE Conceptual Data Model
TRUE
detallestock DETALLESTOCK Conceptual Data Model
TRUE
detalleventa DETALLEVENTA Conceptual Data Model
TRUE
libro LIBRO Conceptual Data Model
TRUE
mensajepeticion MENSAJEPETICION Conceptual Data Model
TRUE
rol ROL Conceptual Data Model
TRUE
stock STOCK Conceptual Data Model
TRUE
sucursal SUCURSAL Conceptual Data Model
TRUE
transaccion TRANSACCION Conceptual Data Model
TRUE
usuario USUARIO Conceptual Data Model
TRUE
venta VENTA Conceptual Data Model
TRUE
Tabla 11. Iista de %$tidades

Entidad Atributos Codigo
Clave
Primaria
Tipo de Dato
Manda
tory
categoria
Libro
idCategorialibro IDCATEGORIALIBRO SI Serial TRUE
nombreCategori
alibro
NOMBRECATEGORIA
LIBRO
Variable
characters (64)
FALSE
descripcionCate
gorialibro
DESCRIPCIONCATEG
ORIALIBRO
Variable
characters (64)
FALSE
Tabla 12. Di##io$ario %$tidad #ategoriaIi,ro
Clave
Primaria
Tipo de Dato
Mandat
ory
categori
arol
idCategoriarol IDCATEGORIAROL SI Serial TRUE
nombreCategori
arol
NOMBRECATEGORIA
ROL
Variable
characters (64)
FALSE
descripcionCate
goriarol
DESCRIPCIONCATEG
ORIAROL
Variable
characters (64)
FALSE
Tabla 13. Di##io$ario %$tidad #ategoriarol

89

Entida
d
Atributos Codigo
Clave
Primaria
Tipo de Dato
Mandator
y
cliente
idCliente IDCLIENTE SI Serial TRUE
ciCliente CICLIENTE

Integer FALSE
direccionClien
te
DIRECCIONCLIEN
TE
Variable characters
(64)
FALSE
nombreClient
e
NOMBRECLIENTE

Variable characters
(64)
FALSE
telefonoClient
e
TELEFONOCLIEN
TE
Variable characters
(64)
FALSE
Tabla 14. Di##io$ario %$tidad #lie$te
Clave
Primaria
Tipo de
Dato
Mandat
ory
detallest
ock
idDetallestock IDDETALLESTOCK SI Serial TRUE
cantidadLibroDetall
estock
CANTIDADLIBRODETALL
ESTOCK
Integer FALSE
fechaIngresoDetall
estock
FECHAINGRESODETALL
ESTOCK
Date FALSE
Tabla 15. Di##io$ario %$tidad detallesto#>
Clave
Primaria
Tipo de
Dato
Mandat
ory
detalleve
nta
idDetalleventa IDDETALLEVENTA SI Serial TRUE
cantidadLibroDetall
eventa
CANTIDADLIBRODETALL
EVENTA
Integer FALSE
Tabla 16. Di##io$ario %$tidad detalleve$ta
Entid
ad
Atributos Codigo
Clave
Primaria
Tipo de Dato
Mandat
ory
libro
idLibro IDLIBRO Si Serial TRUE
nombreLibro NOMBRELIBRO

Variable characters
(64)
TRUE
autorLibro AUTORLIBRO

Variable characters
(64)
FALSE
editorialLibro EDITORIALLIBRO

Variable characters
(64)
FALSE
aniopublicacion
Libro
ANIOPUBLICACIONL
IBRO
Integer FALSE
edicionLibro EDICIONLIBRO

Integer FALSE
idInventario1Lib
ro
IDINVENTARIO1LIB
RO
Variable characters
(64)
FALSE
idInventario2Lib
ro
IDINVENTARIO2LIB
RO
Long integer FALSE
Tabla 17. Di##io$ario %$tidad li,ro
Clave
Primaria
Tipo de
Dato
Mandat
ory
mensajepet
icion
idMensajepeticion IDMENSAJEPETICION SI Serial TRUE
cuerpoMensajepeti
cion
CUERPOMENSAJEPETI
CION
Text FALSE
fechaMensajepetic
ion
FECHAMENSAJEPETICI
ON
Date FALSE
idSucursalMensaje
peticion
IDSUCURSALMENSAJE
PETICION
Integer FALSE
Tabla 18. Di##io$ario %$tidad me$sa5epeti#io$
90

Entida
d
Atributos Codigo
Clave
Primaria
Tipo de Dato
Mandator
y
rol
idRol IDROL SI Serial TRUE
nombreRol NOMBREROL

Variable characters
(64)
FALSE
descripcionR
ol
DESCRIPCIONR
OL
Variable characters
(64)
FALSE
Tabla 19. Di##io$ario %$tidad rol
Entida
d
Atributos Codigo
Clave
Primaria
Tipo de Dato
Mandato
ry
stock
idStock IDSTOCK SI Serial TRUE
descripcionSto
ck
DESCRIPCIONSTO
CK
Variable characters
(64)
FALSE
Tabla 20. Di##io$ario %$tidad sto#>
Entida
d
Atributos Codigo
Clave
Primaria
Tipo de Dato
Mandat
ory
sucur
sal
idSucursal IDSUCURSAL SI Serial TRUE
nombreSucursal NOMBRESUCURSAL

Variable
characters (64)
FALSE
direccionSucurs
al
DIRECCIONSUCURS
AL
Variable
characters (64)
FALSE
telefonoSucursal
TELEFONOSUCURSA
L
Integer FALSE
coordenadasSu
cursal
COORDENADASSUC
URSAL
Variable
characters (64)
FALSE
Tabla 21. Di##io$ario %$tidad s+#+rsal
Clave
Primaria
Tipo de Dato
Mandat
ory
transac
cion
idTransaccion IDTRANSACCION SI Serial TRUE
tipoTransaccion TIPOTRANSACCION

Integer FALSE
fechaTransaccion
FECHATRANSACCIO
N
Date FALSE
descripcionTrans
accion
DESCRIPCIONTRANS
ACCION
Variable
characters (64)
FALSE
Tabla 22. Di##io$ario %$tidad tra$sa##io$
Clave
Primaria
Tipo de Dato
Mandato
ry
usuario
idUsuario IDUSUARIO SI Serial TRUE
nombreUsuar
io
NOMBREUSUARIO

Variable characters
(64)
FALSE
passwordUsu
ario
PASSWORDUSUA
RIO
Variable characters
(64)
FALSE
numcelUsuari
o
NUMCELUSUARIO

Integer FALSE
fecharegUsu
ario
FECHAREGUSUA
RIO
Date FALSE
Tabla 23. Di##io$ario %$tidad +s+ario

91

Entida
d
Atributos Codigo
Clave
Primaria
Tipo de
Dato
Mandator
y
venta
idVenta IDVENTA SI Serial TRUE
fechaVenta FECHAVENTA

Date FALSE
cantidadLibrosVe
nta
CANTIDADLIBROSVEN
TA
Integer FALSE
Tabla 24. Di##io$ario %$tidad ve$ta
92

CAPTULO IV

4 IMPLEMENTACIN Y PRUEBAS

4.1 Implementacin del sistema

%.1.1 *st'ndar de Codificacin

Dentro de la metodologa presentada en el que se desenvuelve este proyecto
tambin se encuentra definido el uso de estndares permitiendo reducir
significativamente la probabilidad de cometer errores de codificacin de esta
manera reduciendo el tiempo de desarrollo y la forma de dar mantenimiento a la
solucin es optimizada adems de contar con una destacada organizacin.

'.1.1.1 -on,enciones generales #ara clases 1 m;to"os

Cada clase tanto en java como en C#.Net constar de datos informativos de
cabecera en este formato:
/**ESCUELA POLITCNICA NACIONAL E.P.N.
* Quito - Ecuador
* Fecha de Creaci! dd/""/####
* Autor! Ir$i Orti% &ir$i'())*'"ai+.co",
* -e.cri/ci0! C+a.e 1a2a Adroid3Acti2it#4
* -e.cri/ci5! C+a.e C6 7e8Ser2ice. 3a."94
*/
'.1.1.2 De/inicin "e clases 1 m;to"os

Las directrices generales para la definicin de clases y mtodos son los
siguientes:
Siempre usar el lenguaje Espaol.
Evitar nombres todo en mayscula o todo en minscula.
93

Evitar abreviaciones con ms de 5 caracteres.
Prefijos deben ser de mximo 3 caracteres
Evitar caracteres especiales como la , ;, < .
Directrices para Web Services:
Los nombres de las clases empezarn con un verbo, este describir las
acciones que realiza. De existir ms de dos palabras en el nombre de la
clase, esta comenzar con la primera letra en mayscula, ejemplo:
ComprobarAutenticidadUsuario.asmx
Los nombres de losmtodos que implementen los servicios web
empezarn nombrados de la misma forma que su clase correspondiente
pero terminara con las siglas WS correspondientes a Web Service. De la
misma manera si existe ms de dos palabras en el nombre del mtodo
comenzar la primera letra en mayscula, ejemplo:
ComprobarAutenticidadUsuarioWS

'.1.1.3 De/inicin "e clases "e acceso a "atos

Las clases dentro de la persistencia de datos del servidor de Web Services
contienen mtodos o funciones que albergan la sintaxis de bases de datos para
realizar las solicitudes de consulta a la misma. Las clases y el modelamiento en
base a arquitectura SOA permiten disgregar las solicitudes en invocaciones por
cada una de ellas.
Para su mejor administracin se dividi las invocaciones de la siguiente manera,
ntese que en la siguiente imagen solo se observarn nicamente dos servicios
web:AniadirClienteNuevoy ComprobarAutenticidadUsuario

Figura

Ntese en la figura las clases ConexionSQLW y ConexionSQL son las clases que
accederen a la consulta en base de datos y la forma de dichas consultas
depender de cada Web Service y estos a su vez depe depender de la sintaxis
que albergue la clase Cadenas SQL

'.1.1.' De/inicin "e clases "e negocio

Las clases de negocios desde el punto de vista integral del sistema sern las
clases Java activitys dentro del modelo de desarrollo Android
Directrices para Activitys en Android SDK:
Los nombres de las clases java empezarn con un verbo, este describir
las acciones que realiza. Asimismo cada clase
terminar con la subfijo
dos palabras en el nombre de la clase, esta comenzar con la primera letra
en mayscula, ejemplo:
Figura29. Diagrama de #lases de a##eso a datos.
las clases ConexionSQLW y ConexionSQL son las clases que
Web Service y estos a su vez depe depender de la sintaxis
que albergue la clase Cadenas SQL.
"e clases "e negocio
dentro del modelo de desarrollo Android.
Directrices para Activitys en Android SDK:
las acciones que realiza. Asimismo cada clase Activity de Android deber
terminar con la subfijo Activity para denotar su diferencia. De existir ms de
en mayscula, ejemplo:
ConsultarLibroActivity.java
94

las clases ConexionSQLW y ConexionSQL son las clases que
Web Service y estos a su vez depe depender de la sintaxis
de Android deber
para denotar su diferencia. De existir ms de
95

Los nombres de los mtodos que se implementen en las Activitys seguirn
la normativa y la nomenclatura descrita por Java. De la misma manera si
existe ms de dos palabras en el nombre del mtodo comenzar la primera
letra en mayscula. La firma de la funcin o el mtodo deber estar
especificado completamente en su implementacin inicial, ejemplo:
String registrarTraslado(String idSucursalDestino,String idSucursalOrigen, String
idLibro, String cantidad)
%.1.2 !lanificacin de pantallas

Los datos recogidos de los Storycards definirn el contenido y los controles que
deben estar presentes para crear las pantallas definidas para la aplicacin.
Desde all se tiene que crear un diseo preliminar tambin llamado
wireframing
47
que se cuenta para cada uno de las pantallas que se detallan en la
siguiente seccin.

'.1.2.1 Diagrama "e +elaciones "e #antalla

En este punto podemos, desde luego, poder identificar y definir las pantallas de la
aplicacin mvil. En el wireframing mencionado en la seccin anterior, se tiene
que los smbolos de unin entre pantallas que tiene una correlacin especfica
sern la lnea y la flecha. Una pantalla A unida por medio de una flecha o una
lnea a una pantalla B deber ser accesible para el usuario directamente a travs
de alguna interaccin que ejerza el usuario sobre algn control de dicha pantalla
A. De esta manera se presenta las pantallas y de cierta manera, la interaccin
que entre ellas habr a la hora de ejecutar la aplicacin. A la hora de expresar
esta forma de notacin se tiene en cuenta que asemeja a un mapa conceptual.

47
Mapa me$tal de la estr+#t+ra / partes $e#esarias de +$a pgi$a we, o apli#a#i$ mvil 0+e se plasma e$
+$ diseDo o di,+5o ple$ame$te estr+#t+ral.

Figura

Una vez que se tiene la solucin diseada en forma de pantallas y con su modelo
interaccional, ya es posible especificar los componentes visuales
partir de este mapa:
Botones que conducirn a diferentes apartados dentro de la aplicacin.
Listas verticales de objetos que representan un conjunto de datos de
manera esquemtica.
Cuadrosde texto que contendrn informacin detallada.
Adicional a esto se puede presentar la informacin
respectivas interacciones por medio de navegacin y mecanismos sofisticados
como el men de navegacin
ejemplo.

Figura30. Mapa de pa$tallas de la 2pp. Mvil
interaccional, ya es posible especificar los componentes visuales
manera esquemtica.
texto que contendrn informacin detallada.
al a esto se puede presentar la informacin y el contenido y sus
interacciones por medio de navegacin y mecanismos sofisticados
navegacinactionbarpropio delsistema operativo Android,

96

interaccional, ya es posible especificar los componentes visuales que tendrn a
y el contenido y sus
interacciones por medio de navegacin y mecanismos sofisticados
sistema operativo Android, por
97

%.1." Seguimiento de iteraciones

Como se menciona en el apartado 3.3.2 de este documento, la planificacin se
plante inicialmente en seis iteraciones. Cada iteracin desde la segunda tiene
asignadas Storycards que han sido ordenadas por su prioridad de acuerdo a la
empresa CODEU, estas Storycards como se menciona anteriormente estn
compuestas por taskcards o tarjetas de tareas representando las tareas
individuales que tendrn que ser completadas para crear valor dentro del
proyecto. La validacin de las taskcards sirvi para la estimacin de tiempo que a
su vez tuvo que ser modificada y ajustada por las razones que se comentarn en
la siguiente seccin.

'.1.3.1 D<a "e Planeacin

La fase de productizacin de la metodologa Mobile D asegura que debe existir un
da de planeamiento, un da de programacin y un da de liberacin para cada
iteracin. A continuacin se detallan las actividades seguidas en cada etapade
esta fase para el prototipo de la aplicacin mvil para el recuento de stocks
einventarios.
%.1.".1.1 An'lisis de requerimientos

Se establecen los requerimientos funcionales y no funcionales detallados en la
seccin 3.2.1 de este documento para el establecimiento de las Storycards y a su
vez de las taskcards.
%.1.".1.2 !laneamiento de -teracin Storycard

Se cre la definicin de cada Storycard de acuerdo a los requerimientos
funcionales detallados anteriormente. A su vez estos requerimientos funcionales
son analizados en el contexto de arquitectura SOA mediante una integracin de
estos con los diagramas BPM mencionados en la seccin 3.3.1 de este
documento. Los Storycards resultantes son:
98

No. Storycard Tipo Plataforma
1 Login de usuarios App. Mvil /
Portal Web de Adm.
2 Gestin de usuarios Portal Web Administracin
3 Gestin de roles Portal Web Administracin
4 Gestin de agrupacin de usuarios Portal Web Administracin
5 Registrar stock actual App. Mvil
6 Registrar venta App. Mvil
7 Registrar traslado App. Mvil
8 Consultar libro existente en otra sucursal App. Mvil
9 Gestin de categoras de libros Portal Web Administracin
10 Gestin de sucursales Portal Web Administracin
11 Generacin de reportes Portal Web Administracin
12 Exportar a diversos formatos Portal Web Administracin
13 Generacin de grficos estadsticos Portal Web Administracin
14 Seguridad App. Mvil /
Portal Web de Adm.
Tabla25. <es+me$ de *tor/#ards "la$ifi#ados

%.1.".1." !laneamiento de -teracin Aas0card

Se plantea varias tareas para satisfacer cada una de las Storycards exitosamente,
la metodologa Mobile-D, como se menciona en el captulo dos de este
documento, recomienda asignar para cada tarea un da en su planificacin para
satisfacer el desarrollo de cada una de ellas y continuar con la siguiente etapa de
esta fase.Los taskcards bsicos que se implementaron para cada Storycard
analizado fueron:

No. Taskcard
1 Poblar Base de Datos con parametrizacin inicial
2 Elaboracin de Clases e Interfaces para Storycard en Servidor Central
99

3 Elaboracin y Publicacin de Web Service(s) para Storycard
4 Diseo de la Interfaz de Usuario en App Mvil para Storycard
5 Elaboracin de Clases e Interfaces para Consumo de Web Services para
Storycard en dispositivo mvil
6 Requerimientos No Funcionales para Storycard
7 Creacin de Storycarden Aplicacin Web Ligera
Tabla26. <es+me$ de Bas>.ards "la$ifi#ados

%.1.".1.% .eneracin de !rue&as de Aceptacin

En base al desarrollo orientado por pruebas, se escriben los casos de prueba que
se debern cumplir en base al anlisis de los requerimientos en contexto con sus
respectivos procesos, es decir, a los Storycards. Cada uno de ellos se prueba en
base a esto permitiendo en primera instancia satisfacer la prueba y una vez
satisfecharefactorizar el cdigo para mejorar la solucin.

'.1.3.2 D<a "e Programacin o 4raba*o

%.1.".2.1 )esarrollo por !rue&as

Si bien es cierto que no se puede probar algo que no se encuentra fabricado ni
implementado, se debe estimar mediante las pruebas que se consideren, el
desarrollo que se debe crear y documentar al momento de la liberacin.
A continuacin se documenta una de las pruebas unitarias que se realizaron con
la clase ComprobarAutenticidadUsuario.asmx.csclase controladora del Web
Service ComprobarAutenticidadUsuarioWS que a su vez es WebMethod
48
.
La funcin de este Web Service detallado en la figura 28lo que permite, como su
nombre lo indica, es comprobar o validar que el nombre de usuario y/o contrasea

48
%l atri,+to :e,Met?od se aso#ia a +$ mGtodo "+,li# para i$di#ar 0+e se desea e&po$er di#?o mGtodo
#omo parte del servi#io :e, (MIJ tomado de la refere$#ia ?ttp!OOmsd$.mi#rosoft.#omOes-
esOli,rar/O,/&d99?&'vWvs.80).asp&

que se ingresa, tanto al portal de administracin como a la aplicacin mvil, exista
de manera correcta en la base de datos y de esta manera validar la seguridad en
el sistema.
Figura 31

Para el correcto funcionamiento de esta
ayudan a entablar comunicacin con la base de datos y nos ayudan para la
lectura de la consulta, estas son
muestran implementadas y detalladas en las figuras
a correcta en la base de datos y de esta manera validar la seguridad en
31. :e, *ervi#e .ompro,ar2+te$ti#idadCs+ario:*
Para el correcto funcionamiento de esta ejecucin se ha creado clases que
de la consulta, estas son CadenasSQL.cs y ConexionSQL.cs
muestran implementadas y detalladas en las figuras29 y 30 respectivamente
100
a correcta en la base de datos y de esta manera validar la seguridad en

:e, *ervi#e .ompro,ar2+te$ti#idadCs+ario:*
se ha creado clases que
ConexionSQL.cs que se
respectivamente.

Figura32. .lase .ade$as*EI
101

Ejecutando el logueo de usuarios ya en el dispositivo mvil, como se demuestr
en la siguiente figura, se comprueba que la clase y el mtodo en g
funcionan.
Figura
Figura33. .lase .o$e&io$*EI
Ejecutando el logueo de usuarios ya en el dispositivo mvil, como se demuestr
en la siguiente figura, se comprueba que la clase y el mtodo en g

Figura34. 7$terfa8 de la 2pp Mvil de 7$i#io
102

Ejecutando el logueo de usuarios ya en el dispositivo mvil, como se demuestra
en la siguiente figura, se comprueba que la clase y el mtodo en general
103

Figura35. 7$terfa8 2pp MvilJ .aso 1 de "r+e,a C$itaria Iogi$ de Cs+ario

104


Figura38. 7$terfa8 2pp Mvil de 7$greso al *istemaJ .aso 3 de "r+e,a C$itaria Iogi$ de Cs+ario

Los resultados obtenidos y resultantes para la prueba unitaria se muestran en la
Tabla 9.
105

Storycard a Probar: Login de usuarios
Datos Resultados Medidos
Usuario en BDD irwin
Password en BDD irwing844
Caso 1
Usuario ingresado irw Tiempo de Ejecucin:3 seg
Password ingresado irwing
Resultado:Mensaje de error (El
Usuario ingresado no existe)
Caso 2
Usuario ingresado irwin Tiempo de Ejecucin:1 seg
Password ingresado irwing
Resultado:Mensaje de error (El
Password no es correcto)
Caso 3
Usuario ingresado irwin Tiempo de Ejecucin: 1 seg
Password ingresado irwing844 Resultado: Usuario Logueado
Tabla27. <es+ltado "r+e,a C$itaria Iogi$ de +s+arios

%.1.".2.2 *$ecucin de -teracin

A continuacin se detalla el desarrollo correspondiente al primer Storycard o
funcionalidad Login de Usuarios, considerando que los siguientes Storycards
son de similar desarrollo.
En el apartado anterior se observ el desarrollo desde el lado de vista del servidor
en el cual existir la clase y mtodo web que implementa el web Service para la
ejecucin del logueo de usuarios, esta hace referencia al mtodo
ComprobarAutenticidadUsuarioWS mostradaen la figura 28. Asimismo se hace
referencia tambin a la Clase CadenasSQLusada para el acceso a datos.
Ya en la aplicacin mvil, la clase java que acceder a este web Service ser la
clase LoginActivity.java y el mtodo en general que se ver puesto a prueba ser
AutentificarUsuario(), detallado en la figura 31.

Figura39

Para el correcto funcionamiento de este mtodo en la aplicacin mvil se ha
creado una clase java que ayuda a entablar comunicacin con el Web Service
SOAP y este a su vez con la base de datos y nos ayudan para la lectura de la
consulta a travs de Interne
funciones que estructuran la solicitud SOAP en pasos, estos pasos se numeran al
final del nombre de cada funcin. Se muestra a continuacin la implementacin de
la cabecera de la clase ConexionSOAP.
Figura40. 7mpleme$ta#i$ de la #a,e#era de la .lase @ava .o$e&io$*12".
39. 7mpleme$ta#i$ MGtodo 2+te$tifi#arCs+ario')
Internet, esta es la clase ConexionSOAP. Esta a su vez tiene
la cabecera de la clase ConexionSOAP.
7mpleme$ta#i$ de la #a,e#era de la .lase @ava .o$e&io$*12".
106

7mpleme$ta#i$ MGtodo 2+te$tifi#arCs+ario')
, esta es la clase ConexionSOAP. Esta a su vez tiene

7mpleme$ta#i$ de la #a,e#era de la .lase @ava .o$e&io$*12".
107

En primerainstancia hay que mencionar que la plataforma de desarrollo Android
no incluye de serie ningn tipo de soporte para el acceso a servicios web de tipo
SOAP. Es por esto que se utilizuna librera externa que tiene como fin facilitar el
acceso a este tipo de Web Services.
Entre la oferta actual, la opcin ms popular y ms utilizada es la librera ksoap2-
android[23]. Esta librera es un fork, especialmente adaptado para Android, de la
antigua librera kSOAP2. Este framework nos permitir utilizar servicios web que
utilicen el estndar SOAP. La ltima versin de esta librera en el momento de
escribir este documento es la 2.6.0, que se puede descargardesde el sitio
49
de su
autor.
Se observa que se crean cinco variables globales para la clase que a su vez
servirn casi como constantes: NAMESPACE, URL, METHOD_NAME,
SOAP_ACTION. Se detallan a continuacin las variables y su funcionalidad.
NAMESPACE: Espacio de nombres utilizado en nuestro servicio web.
URL: Direccin URL para realizar la conexin con el servicio web.
METHOD_NAME: Nombre del mtodo web concreto que vamos a ejecutar.
SOAP_ACTION: Equivalente al anterior, pero en la notacin definida por
SOAP.
Los valores para este mtodo Web Service al que llamara esta funcin quedarn
de la siguiente forma:
NAMESPACE = http://tesisior.no-ip.org/.
URL = http://tesisior.no-
ip.org:8081/ComprobarAutenticidadUsuario.asmx.
METHOD_NAME = "ComprobarAutenticidadUsuarioWS".
SOAP_ACTION = http://tesisior.no-
ip.org/ComprobarAutenticidadUsuarioWS.

49
*itio e$ =oogle .ode.

Las funciones, que a su vez son pasos, dentro de la clase
se muestran implementadas y detalladas en la figura 32 respec
Figura41. "asos impleme$tados para armar peti#i$ *12" e$ .lase .o$e&io$*12"

En primera instancia se crea un nuevo objeto SoapObject el cu
de entrada tendr el NAMESPACE y el nombre del mtodo web. A esta peticin
tendremos que asociar los parmetros de entrada mediante el mtodo
addProperty() al que pasaremos los nombres y valores delos parmetros (que en
nuestro caso se obtendrn de los cuadros de texto
pantalla en la aplicacin mvil
se la implementa en el mtodo
como se muestra en la figura 30.
El segundo paso ser crear el contenedor SOAP (envelope) y asociarl
peticin. Para ello crearemos un nuevo objeto SoapSerializationEnvelope
Las funciones, que a su vez son pasos, dentro de la clase Conexion
se muestran implementadas y detalladas en la figura 32 respectivamente
"asos impleme$tados para armar peti#i$ *12" e$ .lase .o$e&io$*12"
se crea un nuevo objeto SoapObject el cua
nuestro caso se obtendrn de los cuadros de texto usuario y password
pantalla en la aplicacin mvil Login). Esta asociacin de parmetros de entrada
se la implementa en el mtodo AutentificarUsuario() de la clase
como se muestra en la figura 30.
El segundo paso ser crear el contenedor SOAP (envelope) y asociarl
108
onexionSOAP donde
tivamente.

"asos impleme$tados para armar peti#i$ *12" e$ .lase .o$e&io$*12"
al como parmetro
usuario y password de la
Esta asociacin de parmetros de entrada
de la clase LoginActivity
El segundo paso ser crear el contenedor SOAP (envelope) y asociarlo a nuestra
109

indicando la versin de SOAP que vamos a usar (versin 1.1
50
en este prototipo).
Se Indicar adems que se trata de un servicio web .NET activando su propiedad
dotNet como true. Por ltimo, asociaremos la peticin antes creada a nuestro
contenedor llamando al mtodo setOutputSoapObject().
Como tercer paso se crear el objeto que se encargar de realizar la
comunicacin HTTP con el servidor, de tipo HttpTransportSE, al que se pasar la
URL de conexin al servicio web. Por ltimo, completaremos el proceso
realizando la llamada al servicio web mediante el mtodo call().
Como ltimo paso tras la llamada al servicio, ya se est en disposicin de obtener
el resultado devuelto por el mtodo web llamado. Esto se consigue mediante el
mtodo getResponse(). Dependiendo del tipo de resultado que se espera recibir
se deber convertir esta respuesta a un tipo u otro. En este caso, para un tipo de
valor devuelto se convertir la respuesta a un objeto SoapPrimitive, que se podr
trasformar a un solo valor. Asimismo, se tendr otra funcin cuando el valor que
retorne el servicio web sea mayor a un solo valor, por ejemplo una lista.

%.1.".2." *valuacin

En la evaluacin general del sistema se considerarn los parmetros como tiempo
de acceso de los usuarios a los datos, volumen de datos y ancho de banda
utilizado, tiempo de espera de los usuarios tras hacer un clic, niveles de error
existentes tras clics de usuarios. En esta seccin se explicar detalladamente
cada uno de estos parmetros y los resultados obtenidos de las mediciones
realizadas, estas mediciones estarn bajo el concepto de pruebas de rendimiento
de la aplicacin mvil en cuestin.
En la tabla a continuacinse muestra la evaluacin que se realiz con el Storycard
Registrar stock actual. Los resultados obtenidos fueron relativamente muy
similares al resto del sistema.

50
4ersi$ esta,le a la fe#?a de #rea#i$ de este do#+me$to.
110

Nombre del Proyecto: IOR inventarios CODEU.
Storycard a Evaluar: Registrar stock
Poblacin de Pruebas: Se considera:
Mnimo: 1 usuario
Mximo: 10 usuarios
Conectados en rangos de 5 minutos de diferencia.
Conexin de Internet: Se considera:
Servidor:
Ping 12ms
Velocidad de descarga 7.78 Mbps
Velocidad de subida 6.4 Mbps
Dispositivos Mviles Movistar
51
(4 Smartphones):
Ping 128ms
Velocidad de descarga 25.47 Kbps
Velocidad de subida 20.4 Kbps
Dispositivos Mviles Claro
52
(6 Smartphones):
Ping 210ms
Velocidad de descarga 32.41 Kbps
Velocidad de subida 16.7 Kbps
Tabla28. .o$sidera#io$es de$tro de la %val+a#i$ =e$eral de la 2pli#a#i$

%.1.".2.% 3esumen de estadsticas

En la figura a continuacin, se muestra el promedio de uso del procesador del
servidor con uno y diez usuarios en total.En la misma manera se presenta el uso
de la red con un usuario hasta cuando aumentan a 10 los usuarios.

51
%s +$ "romedio ge$eral
52
%s +$ "romedio ge$eral

Figura

Tambin se presenta el tiempo de respuesta para cada usuario cuando se
encuentra logueado en el
diez en total.
Figura
Figura 42. =rfi#o de re$dimie$to ."C / <%D
el tiempo de respuesta para cada usuario cuando se
encuentra logueado en el sistema un usuario y su respuesta cuando aumenta a
Figura43. Biempos de <esp+esta por +s+arios
111

el tiempo de respuesta para cada usuario cuando se
y su respuesta cuando aumenta a

Anlisis de resultados
Se evidencia tanto en los valores de CPU como de
los dichos porcentajes aumentan a partir de los 8 usuarios que utilizan el
sistema paralelamente.
Al observar en la figura 40 se puede observar que tanto un
el sistema como incrementando su nmero a diez, los tiempos de
respuestas de cada uno de ellos
parmetro sino por las actividades que realizan cada uno de ellos.
Los requerimientos o acciones que realiz un usuario y sus tiempos de respuesta
se muestran en el siguiente grfico.
Figura

En el anlisis del anterior grfico se estim
Se estima que la funcionalidad Registrar traslado tienen los tiempos de
respuesta ms altos
datos del servidor que otras tareas como por ejemplo el Login de usuarios
que nicamente hace una llamada a la base de datos del servidor.

Se evidencia tanto en los valores de CPU como de Red de la figura
porcentajes aumentan a partir de los 8 usuarios que utilizan el
sistema paralelamente.
Al observar en la figura 40 se puede observar que tanto un
como incrementando su nmero a diez, los tiempos de
respuestas de cada uno de ellos no se ven alterados o afectados por este
se muestran en el siguiente grfico.
Figura44. Biempos de resp+esta por 6+$#io$alidad
nterior grfico se estim lo siguiente:
respuesta ms altos debido a que se realizan ms peticiones a la base
112
ed de la figura 39 que
porcentajes aumentan a partir de los 8 usuarios que utilizan el
Al observar en la figura 40 se puede observar que tanto un solo usuario en
como incrementando su nmero a diez, los tiempos de
no se ven alterados o afectados por este

debido a que se realizan ms peticiones a la base de
113

La media de los tiempos de respuesta presentados en el grafico es 1.57
segundos lo que demuestra que el sistema an con diez usuarios
utilizando el sistema al tiempo, el servidor sirve para atender las peticiones
en un periodo relativamente rpido.
No existieron picos para ninguna medicin, ni con muchos usuarios ni
haciendo la misma para pocos.
El uso de procesador y red siguen una funcin exponencial que denota
que para mayor nmero de usuarios conectados concurrentemente deber
existir mayor recursos disponibles. Esto denotando que para los primeros
8 usuarios, casi no existe incremento alguno.

114

CAPTULO V

5 CONCLUSIONES Y RECOMENDACIONES

El proyecto de titulacin DESARROLLO DE UNA APLICACIN MVIL PARA
RECUENTO DE STOCKS E INVENTARIOS TRANSFERIDA MEDIANTE WEB
SERVICES fue llevado a cabo con xito, ya que cumpli los objetivos planteados
inicialmente y lo ms valioso fue la experiencia adquirida por el desarrollador y
asimismo autor del presente documento. A continuacin se presentan las
siguientes conclusiones y recomendaciones.

5.1 Conclusiones

5.1.1 Metodologa de Desarrollo

La metodologa Mobile-D es la metodologa que ms se acopla al proyecto
de desarrollo mvil el cual es un enfoque gil, basado en Extreme
Programming XP, metodologa Crystal, y RUP adoptando lo mejor de cada
una de ellas, buscando obtener funcionalidad a travs de muchas
iteraciones en poco tiempo y de manera estable.

Para la aplicacin de esta metodologagil mvil no existe ninguna
herramienta y asimismo poca informacin en Internet que pueda servir
para facilitar el seguimiento de proyectos, esto produce un retraso
destacado en planificacin pero no desmereciendo el valor de esta
metodologa con la cual se pudo incluso reducir tiempos de desarrollo.

115

Al inicio del proyecto se confirma la funcionalidad completa del prototipo
por parte del cliente y se estructuraron los Storycards. Aunque hubieron
cambios se mostr una correcta gestin de cambios entre cada iteracin.

5.1.2 Aplicacin Mvil Para Recuento De Stocks E Inventarios

La Aplicacin Mvil Para Recuento de Stocks e Inventarios puede manejar
n nmero de dispositivos mviles para tomar inventario y hacer todas las
operaciones relacionadas a esta labor en tiempo real, sin embargo, se
debe tomar en cuenta la capacidad de servidor en trminos de memoria y
ancho de banda as como la capacidad de plan de datos en los
dispositivos mviles.
El sistema operativo y en tiempo real ayudar a la toma de inventario y
operaciones relacionadas a este obteniendo informacin al instante. Por
ello reducir costos relacionados a la toma de inventario incluyendo el
tiempo sin atender ni vender en sucursales.
Tanto la administracin del sistema como su operacin puede realizarse a
travs de cualquier conexin a Internet en cualquier lugar del mundo.
La universalidad del sistema operativo Android permite a la Aplicacin
Mvil Para Recuento de Stocks e Inventarios operar en cualquier
plataforma Android desde la versin 2.3 tanto en smartphones como
tabletas de cualquier marca.

5.2 Recomendaciones

5.2.1 Metodologa de Desarrollo

Se recomienda solicitar en primera instancia todos los requerimientos para
el sistema y para la aplicacin, esto se lo recomienda con el fin de no
adjudicarse o asumir dicha funcionalidad en el prototipo.
116

Se recomienda identificar a los interesados en el proyecto para mantener
un mayor seguimiento y retroalimentacin de sus necesidades por parte
de ellos hacia el equipo de trabajo.
La metodologa Mobile D es recomendable para proyectos de alto riesgo y
cuando estos requieran un anlisis detallado de requerimientos, sin
embargo, es necesario recomendar utilizar alguna metodologa
complementaria, como la que se us en este proyecto modelamiento BPM,
para poder profundizar en procesos y requerimientos conjuntos.

5.2.2 Aplicacin Mvil Para Recuento De Stocks E Inventarios

Se recomienda tener dispositivos mviles conectados a Internet mediante
un plan de datos con un proveedor de telefona, de esta manera se podr
trasladar dicho dispositivos entre sucursales y se tendr el mayor tiempo
de conexin disponible.

Cuando se tiene tecnologas que no son conocidas, se corre el riesgo de
que no se llegue a los resultados esperados, por lo tanto, se recomienda
realizar pruebas de concepto y buscar soporte con personas expertas en
el tema, de esta forma se asegura la funcionalidad del proyecto.

Se recomienda implementar el sistema para otros mdulos, por ejemplo
mdulo comercial o contable, ya que se tiene anexin con la seccin de
ventas y clientes,y podra suponer una mejora en la gestin al momento
de facturar y llevar una gestin comercial.

117

BIBLIOGRAFIA

K1L M. 2. 7. 3. 3. Mg+e8 "Gre8J 7$trod+##i$ a la gesti$ de sto#>sJ %spaDa! 7deaspropias %ditorial
*.IJ 2006.
K2L Q:i>ipediaJR 6+$da#i$ :i>imediaJ 7$#J 2011. K%$ l$eaL. 2vaila,le!
?ttp!OOes.wi>ipedia.orgOwi>iO"r+e,aVdeV#o$#epto. KXltimo a##eso! 2,ril 2012L.
K3L .. M. <o#aJ "res+p+estos para empresas de ma$+fa#t+raJ 3arra$0+illa! C$iversidad del ;orteJ
2004.
K4L @. 6errerJ QIi,re*oftJR K%$ l$eaL. 2vaila,le!
?ttp!OOli,resoft.dat.es#et.+r5#.esO?tmlOdow$loadsOferrer-20030312.pdf . KXltimo a##eso! 26
2,ril 2012L.
K5L @. .a$osJ ". Ietelier / .. "e$adGsJ Metodologas giles e$ el desarrollo de *oftware.J D*7. -
C$iversidad "olitG#$i#a de 4ale$#ia.
K6L 4. <a?imia$ / <. <amsi$J Desig$i$g a$d agile met?odolog/ for mo,ile software developme$t!
a ?/,rid met?od e$gi$eeri$g approa#?.J Marra>e#?! *e#o$d 7$ter$atio$al .o$fere$#e o$ J
2008.
K7L ". 2,ra?amsso$J 2. Aa$?i$evaJ A. A+l>>oJ B. 7?meJ @. @YYli$o5a / M. Por>alaJ Mo,ile-D! a$ agile
approa#? for mo,ile appli#atio$ developme$t.J 4a$#o+ver! .ompa$io$ Bo t?e 19t? 2$$+al
2.M *7="I2; .o$fere$#e o$ 1,5e#t-1rie$ted "rogrammi$g */stemsJ Ia$g+agesJ a$d
2ppli#atio$sJ 2004.
K8L B. 7?me / ". 2,ra?amsso$J QB?e Cse of 2r#?ite#t+ral "atter$s i$ t?e 2gile *oftware
Developme$t of Mo,ile2ppli#atio$sJR vol. 8J $Z 2J 2005.
K9L QMo,ile-D ?omepageJR K%$ l$eaL. 2vaila,le! ?ttp!OOagile.vtt.fiOmo,iled.?tml. KXltimo a##eso!
26 2,ril 2012L.
K10
L
=. 6orma$ / @. [a?ar5o$J QB?e #?alle$ges of mo,ile #omp+ti$gJR vol. 27J $Z 4J 1994.
K11
L
7. *. Ae/esJ @+st %$o+g? :ireless .omp+ti$gJ "reti$#e AallJ 2002.
K12
L
M. D+$lop / *. 3rewsterJ QB?e .?alle$ge of Mo,ile Devi#es for A+ma$ .omp+ter
7$tera#tio$JR vol. 6J $Z 4J 2002.
118

K13
L
QMo,ile-D #ase st+dies ?omepageJR K%$ l$eaL. 2vaila,le! ?ttp!OOagile.vtt.fiO#ase.?tml. KXltimo
a##eso! 26 2,ril 2012L.
K14
L
P. 3e#>J %&treme "rogrammi$g %&plai$ed! %m,ra#e.?a$geJ 2ddiso$-:esle/J 2000.
K15
L
2. .o#>,+r$J .r/stal .learJ 2 A+ma$-"oweredMet?odolog/ for *mall BeamsJ 2ddiso$-:esle/J
2004.
K16
L
". Pr+#?te$J B?e <atio$al C$ified "ro#ess! 2$ 7$trod+#tio$.J 2ddiso$-:esle/ "rofessio$alJ
1999.
K17
L
6+$da#i$ :i>imediaJ 7$#J 16 2,ril 2012. K%$ l$eaL. 2vaila,le!
?ttp!OOes.wi>ipedia.orgOwi>iODesarrolloVg+iadoVporVpr+e,as. KXltimo a##eso! 09 Ma/o 2012L.
K18
L
A. Aed,erg / @. 7isa>>aJ QBe#?$i#al <eviews i$ 2gile Developme$t! .ase Mo,ile-D'BM)J E+alit/
*oftwareJ 7$ter$atio$al .o$fere$#eJR de QSIC'06J 2006.
K19
L
Q:e, *ervi#esJR 6+$da#i$ :i>imediaJ 7$#.JJ 07 Ma/o 2012. K%$ l$eaL. 2vaila,le!
?ttp!OOes.wi>ipedia.orgOwi>iO*ervi#ioVwe,. KXltimo a##eso! 13 Ma/o 2012L.
K20
L
Q2$droidJR 6+$da#i$ :i>imediaJ 7$#.J 9 Ma/o 2012. K%$ l$eaL. 2vaila,le!
?ttp!OOes.wi>ipedia.orgOwi>iO2$droid. KXltimo a##eso! 11 Ma/o 2012L.
K21
L
QMi#rosoft "arter$ %(1JR K%$ l$eaL. 2vaila,le!
?ttp!OOwww.e&o.#om.arOe&osOpagi$asOpla$tillasV#o$te$idoO"age.asp\se##io$W258]pagi$aW4
7]pla$tillaW"age.asp. KXltimo a##eso! 25 Ma/o 2012L.
K22
L
1. *. a. A. A+l>>oJ QMo,ile-D O <elease "ro5e#t "ro#ess O %&ploreJR K%$ l$eaL. 2vaila,le!
?ttp!OOagile.vtt.fiOmo,iled.?tml. KXltimo a##eso! 16 @+lio 2012L.
K23
L
D. ParlmJ Q>soap2-a$droidJR =oogle .odeJ 11 2012. K%$ l$eaL. 2vaila,le!
?ttps!OO#ode.google.#omOpO>soap2-a$droidO. KXltimo a##eso! 04 2013L.
K24
L
". 2,ra?amsso$J Mo,ile software developme$t F t?e ,+si$ess opport+$it/ of toda/J
7$ter$atio$al .o$fre$#e of *oftware Developme$tJ 2005.
K25
L
3. 3oe?m / B. <. J 3ala$#i$g agilit/ a$d dis#ipli$e! 2 g+ide for t?e perpe&ledJ 2ddiso$-:esle/J
2003.
K26
L
3. 3oe?mJ 2gile a$d pla$-drive$ met?odsJ C*.-.*% 2ffilities^:or>s?opJ 2002.
K27
L
Q"r+e,as de <e$dimie$to del *oftwareJR :i>ipediaJ 5 @+$io 2013. K%$ l$eaL. 2vaila,le!
?ttp!OOes.wi>ipedia.orgOwi>iO"r+e,asVdeVre$dimie$toVdelVsoftware. KXltimo a##eso! 5 @+$io
119

2013L.

120

ANEXOS

Formato y Ejemplo de Documentacin de Web Services
Servicio Web "ObtenerContextoUsuarioWS"
1. Parmetros de Entrada
La operacin ObtenerContexto de Usuariopermite consultar todos los elementos
de la Base de Datos asociados coincidentes a un usuario dado. Dado un nombre,
devuelve todas las especificaciones de sucursal, rol, telfono celular, fecha de
registro e id que coinciden con este.
Parmetros de entrada del servicio Web " ObtenerContexto de Usuario"
Nombre Tipo Valores
usuario String
Cadena a buscar.
Ejemplos: "victor2" o "carlos13"
2. Parmetros de Salida
Parmetros de Salida
Nombre Tipo Valores
sucursal String Sucursales registradas en la base de Datos.
rol String Roles registrados en la base de datos
celular number Numero de telfono celular
fecha de registro date Fecha y hora
id integer identificador de usuario

121

a. Descripcin de los parmetros de Salida
Descripcin de los parmetros de Salida
Tipo Descripcin
sucursal El nombre de sucursal al que est asignado el usuario que ingresa en
el sistema. De esta manera el sistema detecta con que sucursal
realizar las operaciones necesarias.
rol El rol que est ligado el usuario. Permite personalizar la seguridad y el
acceso dependiendo el usuario que se loguea en el sistema.
celular Telfono celular del usuario previamente registrado en la base de
datos. Se muestra con fines informativos.
fecha de
registro
Fecha en la cual el usuario fue registrado en la base de datos.
id
Es el cdigo identificador del usuario en la base de datos.

CD 5221

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CD 5221

Încărcat de

Drepturi de autor:

Formate disponibile

ESCUELA POLITCNICA NACIONAL

FACULTAD DE INGENIERIA DE SISTEMAS

S-ar putea să vă placă și