ESCUELA POLITCNICA DEL EJRCITO

DPTO. DE CIENCIASDE LA COMPUTACIN

CARRERA DE INGENIERA DE SISTEMAS E INFORMTICA



MTODO GIL SCRUM, APLICADO A LA
IMPLANTACIN DE UN SISTEMA INFORMTICO PARA
EL PROCESO DE RECOLECCIN MASIVA DE
INFORMACIN CON TECNOLOGA MVIL





Previa la obtencin del Ttulo de:




INGENIERO EN SISTEMAS E INFORMTICA






POR: KLEBER MANUEL TOAPANTA CHANCUSI




Sangolqu, noviembre 2012


i

CERTIFICACIN

Certifico que el presente trabajo fue realizado en su totalidad por el Sr. Klber
Manuel Toapanta Chancusi como requerimiento parcial a la obtencin del ttulo
de INGENIERO EN SISTEMAS E INFORMTICA.



Noviembre del 2012


_________________________________
ING. MARCO VERGARA
DIRECTOR



ii

LISTADO DE TABLAS
Tabla 1. Matriz de Soluciones, diagrama CausaEfecto (Parte I) ...................... 6
Tabla 2. Matriz de Soluciones, diagrama CausaEfecto (Parte II) ..................... 7
Tabla 3. Comparacin entre metodologas giles y tradicionales .................... 27
Tabla 4. Roles del SCRUM .............................................................................. 32
Tabla 5.Tcnicas de pruebas ........................................................................... 53
Tabla 6.Simbologia utilizada en los diagramas ................................................ 65
Tabla 7. Requerimientos Funcionales/No Funcionales Sprint 0 .................... 66
Tabla 8. Equipo de Trabajo y Roles ................................................................. 70
Tabla 9. Backlog Producto ............................................................................... 71
Tabla 10.Requerimientos Funcionales/No Funcionales- Sprint1 ...................... 75
Tabla 11.Historias de Usuario - Sprint 1 ........................................................... 76
Tabla 12.Actores del sistema ........................................................................... 77
Tabla 13.Especificacin del caso de uso: Gestionar Usuarios ......................... 79
Tabla 14.Especificacin del caso de uso: Gestionar Equipos .......................... 80
Tabla 15.Especificacin del caso de uso: Seleccionar Usuario ........................ 81
Tabla 16.Especificacin del caso de uso: Asignar/Reasignar Responsable .... 82
Tabla 17.Especificacin del caso de uso: Seleccionar Perfil ............................ 83
Tabla 18.Especificacin del caso de uso: Seleccionar Formulario ................... 83
Tabla 19.Especificacin del caso de uso: Gestionar Perfiles ........................... 84
Tabla 20.Especificacin del caso de uso: Gestionar Formularios .................... 85
Tabla 21.Especificacin del caso de uso: Definir Usuarios del perfil ................ 86
Tabla 22.Especificacin del caso de uso: Definir Formularios del perfil ........... 87
Tabla 23.Especificacin del caso de uso: Gestin de Catlogos ..................... 88
Tabla 24. Backlog Sprint Mdulo de Administracin ...................................... 92
Tabla 25.Requerimientos Funcionales/No Funcionales- Sprint 2 ..................... 95
Tabla 26.Historias de Usuarios Sprint 2 ........................................................ 96
Tabla 27.Actores del sistema ........................................................................... 97
Tabla 28.Especificacin del caso de uso: Carga Planes de trabajo ................. 99
Tabla 29.Formato de archivo para intercambio magntico............................. 100
Tabla 30.Especificacin del caso de uso: Consultar Plan de trabajo ............. 101
Tabla 31.Especificacin del caso de uso: Seleccionar Lecturas .................... 102
Tabla 32.Especificacin del caso de uso: Asignar/Reasignar Lecturas ......... 102


iii

Tabla 33.Especificacin del caso de uso: Consultar Asignacin .................... 103
Tabla 34.Especificacin del caso de uso: Consultar estado Sincronizacin .. 104
Tabla 35.Requerimientos Funcionales/No Funcionales- Sprint 3 ................... 110
Tabla 36.Historias de Usuarios Sprint 3 ...................................................... 111
Tabla 37.Especificacin del caso de uso: Login App Mvil ............................ 113
Tabla 38.Especificacin del caso de uso: Mantenimiento Aplicacin mvil.... 114
Tabla 39.Especificacin del caso de uso: Seleccionar Lectura ...................... 115
Tabla 40.Especificacin del caso de uso: Tomar Lectura .............................. 115
Tabla 41.Cdigos de novedades .................................................................... 117
Tabla 42.Ejemplo Validacin Giro .................................................................. 118
Tabla 43.Especificacin del caso de uso: Desbloquear Lectura .................... 118
Tabla 44.Especificacin del caso de uso: Registrar Excedente ..................... 119
Tabla 45.Requerimientos Funcionales/No Funcionales- Sprint 4 ................... 126
Tabla 46. Historia de usuario Sincronizacin - Alcance ............................... 126
Tabla 47. COPIA - Especificacin del caso de uso: Sincronizar Lecturas en
Lnea .............................................................................................................. 128




iv

LISTADO DE FIGURAS
Figura 1. Diagrama Causa-Efecto. Anlisis proceso recoleccin masiva de
informacin para ASISTECOM ........................................................................... 5
Figura 2. Rational Unified Process ................................................................... 16
Figura 3. MICROSOFT SOLUTION FRAMEWORK ......................................... 17
Figura 4. SCRUM ............................................................................................. 21
Figura 5. Extreme Programming ...................................................................... 22
Figura 6. Crystal Methodologies ....................................................................... 23
Figura 7. Dynamic Systems Development Method ........................................... 24
Figura 8. Feature -DrivenDevelopment ............................................................ 25
Figura 9. Lean Development ............................................................................ 26
Figura 10. Elementos del SCRUM ................................................................... 31
Figura 11. SPRINT ........................................................................................... 35
Figura 12. Builds continuos .............................................................................. 39
Figura 13.Modelo V ......................................................................................... 51
Figura 14.El modelo W ..................................................................................... 51
Figura 15.Modelo de Pruebas Orientada a Objetos para el Ciclo de Vida
Completo. ......................................................................................................... 52
Figura 16.Plantilla para especificacin de casos de uso. ................................. 57
Figura 17.Ejemplo Diagrama Entidad Relacin ................................................ 58
Figura 18. Definiciones Sprintometer ............................................................... 59
Figura 19.Herramienta de desarrollo VS2010. ................................................. 60
Figura 20.Proceso de Lectura de medidores de consumo IN SITU ................. 62
Figura 21 - Diagrama de procesos ................................................................... 64
Figura 22.Escala Importancia Definida por Product Owner. ............................. 71
Figura 23.Modelo de Datos del Sistema........................................................... 72
Figura 24. Arquitectura Aplicacin .................................................................... 74
Figura 25.Casos de uso - Administracin ......................................................... 78
Figura 26.Diagrama Entidad Relacin-Mdulo Administracin ........................ 89
Figura 27.Arquitectura Aplicacin de escritorio Mdulo de Administracin ... 91
Figura 28. Componentes - Mdulo Administracin ........................................... 91
Figura 29. Backlog Sprint 1- Sprint to Meter ..................................................... 93


v

Figura 30.Reporte de errores JIRA ............................................................... 94
Figura 31.Casos de Uso - Mdulo Gestin....................................................... 98
Figura 32.Diagrama Entidad Relacin-Mdulo Gestin.................................. 105
Figura 33. Arquitectura Aplicacin - Seccin Aplicacin de escritorio ............ 107
Figura 34.Componentes - Mdulo Gestin ..................................................... 107
Figura 35.Diagramas de casos de uso - Aplicacin Mvil .............................. 112
Figura 36. Modelo de datos - Aplicacin Mvil. .............................................. 120
Figura 37.Arquitectura Aplicacin Mvil ......................................................... 121
Figura 38. Historia de Usuario Sincronizacin en lnea................................ 127
Figura 39. COPIA - Diagrama Entidad Relacin-Aplicacin Mvil .................. 129
Figura 40. Componentes a exponer en Servicio WCF ................................... 130
Figura 41. Diagrama Fsico SISTEMA............................................................ 131
Figura 42. Mtodo SCRUM adaptado al proyecto R.M.I con dispositivos mviles
....................................................................................................................... 134
Figura 43.Ciclo de vida en cascada en cada Sprint ....................................... 135
Figura 44.Ejecucin proyecto R.M.I con dispositivos mviles ........................ 135
Figura 45. Ejemplo buenas prcticas programacin ...................................... 138




vi

LISTADO DE ANEXOS
ANEXO A - PRUEBAS REALIZADAS EN LA ETAPA DE CODIFICACIN ... 144
ANEXO B - GLOSARIO DE TRMINOS Y ABREVIATURAS. ....................... 153
ANEXO C - ACTAS DE REUNIONES CON PRODUCT OWNER .................. 155
ANEXO D - MANUAL DE USUARIO .............................................................. 174
ANEXO E - CARTA DE AUSPICIO Y ACEPTACIN..................................... 193




vii

NDICE DE CONTENIDO
CAPTULO 1 ...................................................................................................... 3
1.1. Introduccin ....................................................................................... 3
1.2. Planteamiento del problema .............................................................. 5
1.3. Alcance .............................................................................................. 9
1.4. Objetivos .......................................................................................... 11
CAPTULO 2 .................................................................................................... 13
2.1. Marco Terico ..................................................................................... 13
2.2. Metodologas Tradicionales de Desarrollo de Software ..................... 14
2.2.1. Principales metodologas Tradicionales ....................................... 15
2.3. Metodologas giles de Desarrollo de Software ................................. 17
2.3.2. El manifiesto gil .......................................................................... 18
2.3.3. Principales metodologas giles ................................................... 21
2.4. Metodologas giles vs. Tradicionales ................................................ 26
2.5. SCRUM ............................................................................................... 28
2.5.1. Introduccin .................................................................................. 28
2.5.2. La Esencia De SCRUM ................................................................ 29
2.5.3. Elementos del SCRUM ................................................................. 30
CAPTULO 3 .................................................................................................... 42
3.1. Metodologa......................................................................................... 42
3.2. Desarrollo iterativo e incremental ........................................................ 43
3.3. Etapas Del Proceso De Desarrollo ...................................................... 44
3.3.1. Planificacin.................................................................................. 45
3.3.2. Anlisis ......................................................................................... 46
3.3.3. Diseo .......................................................................................... 46
3.3.4. Construccin y Pruebas ................................................................ 47


viii

3.3.5. Implementacin ............................................................................ 55
3.4. Herramientas ....................................................................................... 56
3.4.1. Tcnicas de relevamiento ............................................................. 56
3.4.2. Casos de Uso ............................................................................... 56
3.4.3. Diagrama de Entidad Relacin (DER) .......................................... 57
3.4.4. Sprintometer ................................................................................. 58
3.4.5. Visual Studio 2010 ........................................................................ 59
3.4.6. Jira ................................................................................................ 60
CAPTULO 4 .................................................................................................... 61
4.1. Ejecucin del Proyecto ........................................................................ 61
4.1.1. Planificacin.................................................................................. 61
4.1.2. Alcance del software ..................................................................... 68
4.1.3. Conformacin del equipo de trabajo ............................................. 69
4.1.4. Definicin del Backlog del Producto. ............................................ 70
4.1.5. Diseo .......................................................................................... 72
4.1.6. Sprint1 Mdulo de Administracin .............................................. 74
4.1.7. Sprint2 Mdulo de Gestin ......................................................... 95
4.1.8. Sprint3 Aplicacin Mvil ........................................................... 110
4.1.9. Sprint4 Sincronizacin en Lnea ............................................... 125
4.2. Conclusiones ..................................................................................... 131
4.3. Recomendaciones ............................................................................. 139
BIBLIOGRAFA .............................................................................................. 141
ANEXO A - PRUEBAS REALIZADAS EN LA ETAPA DE CODIFICACIN ... 144
Pruebas Sprint 1Mdulo de administracin .............................................. 144
Pruebas Sprint 2Mdulo de Gestin ......................................................... 149
Pruebas Sprint 3 Aplicacin Mvil ............................................................ 151
ANEXO B - GLOSARIO DE TRMINOS Y ABREVIATURAS. ....................... 153


ix

ANEXO C - ACTAS DE REUNIONES CON PRODUCT OWNER .................. 155
Acta N2 Sprint 0 .................................................................................. 155
Acta N3 Sprint 1 .................................................................................. 158
Acta N5 Sprint 2 .................................................................................. 163
Acta N6 Sprint 3 .................................................................................. 169
ANEXO D - MANUAL DE USUARIO .............................................................. 174
Prerrequisitos .............................................................................................. 175
Instalacin ................................................................................................... 175
Aplicacin principal ..................................................................................... 177
Generalidades ......................................................................................... 177
Mdulo de administracin ........................................................................... 181
Administracin de usuarios ...................................................................... 181
Administracin de equipos ....................................................................... 182
Asignacin de equipos ............................................................................. 182
Mdulo de Gestin ...................................................................................... 184
Cargar planes de trabajo ......................................................................... 184
Cambiar estado de los planes de trabajo................................................. 185
Asignacin de lecturas ............................................................................. 186
Sincronizacin de datos asignados ......................................................... 187
Rendir planes de trabajo .......................................................................... 188
Aplicacin mvil .............................................................................................. 189
Prerrequisitos .............................................................................................. 189
Instalacin ................................................................................................... 189
Acceso a la aplicacin ................................................................................. 190
Gestin de lecturas en campo..................................................................... 190
DESBLOQUEO DE LECTURAS ................................................................. 191
Lecturas Excedentes ................................................................................... 192


x

Sincronizacin en lnea ............................................................................... 192
ANEXO E - CARTA DE AUSPICIO Y ACEPTACIN..................................... 193
BIOGRAFA .................................................................................................... 194



1

RESUMEN
El mercado actual es altamente competitivo y cambiante. En ese contexto el
desarrollo del Software busca bsicamente rapidez, calidad y reduccin de costos
en la ejecucin de sus proyectos; para asumir estos retos es necesario tener
agilidad y flexibilidad. Estas caractersticas se constituyen en el fundamento
mismo de las metodologas agiles de desarrollo.
En el mbito de las metodologas de desarrollo de software existe un gran nmero
de alternativas y los responsables de cada proyecto tienen la difcil tarea de
seleccionar la alternativa que mejor se ajuste a sus necesidades y recursos.
El presente estudio se enfoc en el anlisis del mtodo gil SCRUM para la
implementacin de una metodologa aplicada al desarrollo de software para la
recoleccin masiva de informacin con dispositivos mviles.
La ejecucin y culminacin del proyecto permiti establecer una metodologa
basada en SCRUM, complementada con otros mtodos. El resultado es un
producto de software funcional, en cuyo desarrollo se pudo demostrar la validez
de SCRUM aplicado a proyectos de software de mediano tamao, en entornos
cambiantes, con grupos de trabajo pequeos que involucran permanentemente al
dueo del producto.


2

ABSTRACT
The current market is very competitive and always is changing. For this reason
the development of the Software is looking for speed, quality and cost reduction in
the execution of their projects, to take on these challenges is necessary to have
agility and flexibility, these characteristics constitute the basis for agile
development methodologies.
In the area of the methodologies used to address software development projects
there are a lot of alternatives, and the responsible of each project must to select
the best alternative according their needs and resources.
The project is focused on the study of agile method SCRUM and implementation
of a methodology applied to software development for the massive collection of
information with mobile devices, using SCRUM.
The execution and completion of the project allowed to establish a methodology
based in SCRUM, supplemented with other methods. The result is a functional
software product, that helped to demonstrate the effectiveness of SCRUM
applied to software projects of medium size, in changing environments, with small
groups of work constantly involving the product owner.



3

CAPTULO 1
1.1. Introduccin
Existen en el medio muchas empresas para las cuales la recoleccin de
datos in situ es parte fundamental de la ejecucin de sus procesos operativos,
por ejemplo Elctrica de Quito, Empresa Metropolitana de Agua Potable, Ilustre
Municipio Quito, entre otras a nivel nacional; para las que el levantamiento de
informacin (consumo mensual de medidores, informacin catastral, etc.) es
indispensable en la ejecucin de otros procesos como recaudacin, facturacin,
anlisis, registro, etc. y para los cuales es necesario una eficiente y oportuna
recoleccin de datos in situ.
En ocasiones este proceso se poda llevar a cabo de una forma completamente
manual, utilizando nicamente formularios y personal dedicado a llenarlos con la
informacin requerida. En estos casos, el posterior procesamiento (manual o
automtico) de la informacin recolectada, puede presentar una alta probabilidad
de obtener resultados incorrectos derivados de errores de caligrafa o de
interpretacin de los datos recolectados, errores de transcripcin, prdidas de
informacin debido a los medios utilizados, entre otros.
Como respuesta a esta problemtica y de la mano de los avances tecnolgicos,
surgen en el mercado, una gran variedad de dispositivos para la recoleccin de
informacin in situ, los cuales disminuyen significativamente el riesgo de errores
que se presentaban con un proceso manual. Estos dispositivos ofrecen un mayor
volumen de trabajo y agilitan el procesamiento de la informacin recolectada,

4

puesto que esta puede transferirse desde y hacia algn sistema informtico que la
procese los datos.
Los primeros equipos recolectores de datos eran grandes, pesados, equipados
con bateras de corta duracin, arquitectura cerrada que limitaba su utilizacin,
con funcionalidades bastante limitadas, todo esto sumado a los altos costos de
adquisicin y mantenimiento.
En la actualidad, los avances tecnolgicos en equipos de telefona mvil, su gran
difusin, relativos bajos costos, entre otras caractersticas, hacen de estos una
gran alternativa en el mejoramiento y optimizacin del proceso de recoleccin
masiva de informacin in situ, especialmente por la posibilidad de transferir
informacin en lnea, agilitando enormemente el proceso.
En este contexto, ASISTECOM Ca. Ltda. , es una empresa dedicada a brindar
servicios de asistencia tcnica, financiera y comercial, enfocada especialmente a
empresas de servicios bsicos a nivel nacional. Brinda para algunos de sus
clientes el servicio de recoleccin masiva de informacin in situ. Para ello, la
empresa utiliza actualmente un sistema informtico de propiedad de un proveedor
externo. La creciente demanda de los servicios prestados por la empresa y la
necesidad de ajustarse a los requerimientos particulares de cada uno de sus
clientes, hace que la empresa ASISTECOM Ca. Ltda. decida auspiciar el
presente proyecto , con la finalidad de obtener un herramienta informtica propia,
que le permita: gestionar en forma gil, oportuna y eficiente el proceso de
recoleccin masiva de informacin para uno de sus principales clientes (Empresa
Elctrica de Quito), aprovechar al mximo la tecnologa disponible en el mercado
tanto en el sector de la informtica como de la tecnologa mvil y hacer que la

5

nueva herramienta se convierta en poco tiempo en una alternativa viable al
sistema informtico actual.
1.2. Planteamiento del problema
Para exponer los factores que justifican la ejecucin del presente proyecto,
se usar un Diagrama CausaEfecto
1
(o Espina de pescado). En este diagrama,
se precisa un problema central o efecto, en este caso definido por el proceso de
RECOLECCIN MASIVA DE INFORMACIN IN SITU; para este efecto o
consecuencia, se identifican los factores causales ms importantes representados
por las espinas, como lo muestra la siguiente figura.

Figura 1. Diagrama Causa-Efecto. Anlisis proceso recoleccin masiva de informacin para
ASISTECOM

1
Apuntes de Administracin. (s.f.). apuntesyama. Recuperado el 10 de 02 de 2012, de
http://apuntesyama.galeon.com/ischikawa.html



6

1.2.1. Matriz de soluciones
Una vez realizado un anlisis de causa efecto, es necesario realizar una
ponderacin de la misma para identificar las soluciones que causan mayor
impacto y tomar decisiones.
Tabla 1. Matriz de Soluciones, diagrama CausaEfecto (Parte I)
C
R
I
T
E
R
I
O
S

P
E
S
O

A

C
A
U
S
A

S
U
B

C
A
U
S
A
S

R
E
S
U
M
E
N

A
C
C
I
O
N
E
S

/

S
O
L
U
C
I
O
N
E
S

P
O
N
D
E
R
A
C
I

N

B











1
-

1
0

C
U
A
N
T
I
F
I
C
A
C
I

N

C
R
I
T
E
R
I
O
S

TOTAL
C





E
q
u
i
p
o
s


1

S
u
b
u
t
i
l
i
z
a
d
o
s

(1) Nuevas
tecnologas
Existen nuevas
tecnologas, pero la
empresa no pude
hacer uso de estas
Utilizacin de nuevas
tecnologas
7
16 16
(0) Nuevos
Equipos
Existen equipos
ms eficientes, de
menor costo, pero
la empresa no
puede utilizarlos
Adquisicin de Nuevos
equipos
4
S
o
p
o
r
t
e

T

c
n
i
c
o


(2)
Frecuencia
Se recurre con alta
frecuencia al
soporte tcnico del
actual proveedor
Disminuir la necesidad de
soporte tcnico
5






S
o
f
t
w
a
r
e

2

S
o
p
o
r
t
e

T

c
n
i
c
o


(5)
Frecuencia
Se recurre con alta
frecuencia al
soporte tcnico del
actual proveedor
Disminuir la necesidad de
soporte tcnico
8
22 44
M
a
n
t
e
n
i
m
i
e
n
t
o

(6) Cambios
frecuentes
El proceso requiere
con frecuencia de
cambios en el
Sistema Informtico
Software propio,
facilidades para
mantenimiento en el
software
8
P
l
a
t
a
f
o
r
m
a

i
n
f
o
r
m

t
i
c
a


(7)
Tecnologa en
desuso
El actual proveedor
obliga a la
utilizacin de
tecnologa e
desuso
Eliminar esta necesidad 4
(8) Sin
soporte
tcnico
La tecnologa en
desuso, no tiene
soporte tcnico.
Utilizar tecnologa de fcil
acceso en el mercado.
2



7


Tabla 2. Matriz de Soluciones, diagrama CausaEfecto (Parte II)


P
e
r
s
o
n
a
s

3

T
i
e
m
p
o
s

d
e

t
r
a
b
a
j
o

(3) Procesos
lentos
Existen procesos
que son demasiado
lentos con el
proveedor actual.
Buscar alternativas a los
procesos que toman
demasiado tiempo.
9
14 42 (
1
2
)

C
o
n
t
r
o
l


Se requiere
mantener mayor
control sobre el
trabajo del
personal.
Controlar de forma
eficiente el trabajo del
personal operativo
3
(
4
)

F
a
c
i
l
i
d
a
d

d
e

U
s
o

(
s
o
f
t
w
a
r
e
)


El software de
recoleccin de
datos debe ser de
fcil utilizacin para
el personal
operativo.
Mejorar facilidad de uso 2






A
d
m
i
n
i
s
t
r
a
c
i

n


4

C
o
s
t
o
s

p
o
r

s
o
p
o
r
t
e

t

c
n
i
c
o


11 Excesivo
Gastos elevados
por mantenimiento
y soporte tcnico.
Reduccin de gastos por
soporte tcnico.
8
26 104
(
1
0
)

C
a
l
i
d
a
d

d
e

s
e
r
v
i
c
i
o


Se busca ampliar la
calidad del servicio
que la empresa
presta a sus
clientes
Mejorar calidad de
servicio que se ofrece a
los clientes.
9
(
9
)

I
m
a
g
e
n

i
n
s
t
i
t
u
c
i
o
n
a
l


La calidad del
servicio influye en
la imagen de la
empresa.
Mejorar calidad para
mejorar imagen
institucional
9

Nota: El valor ms alto en la columna de ponderacin de criterios es el indicador de mayor
importancia para atacar el problema. Fuente: Elaboracin propia.
a
Importancia del criterio respecto del tema analizado.
b
Ponderacin de 0 a 10 en cada sub criterio, siendo 0 el calificativo de menor importancia y 10 el
de mayor importancia.
c
Sumatoria de las ponderaciones de cada sub criterio, agrupados en criterios y multiplicado por el
peso del criterio.





ESPACIO EN BLANCO INTENCIONAL


8

1.2.2. Justificacin

Una vez analizado el proceso de recoleccin masiva de informacin in situ para
la empresa ASISTECOM Ca. Ltda. , se determina que el principal objetivo es
brindar un mejor servicio as como optimizar el proceso para reducir los gastos
generados en su ejecucin. Se determina entonces que las principales
deficiencias en la ejecucin del proceso se encuentran ligadas a problemas de
tecnologas de informacin, por lo que es necesario enfocarse en resolver estos
problemas para optimizar a la brevedad posible el mencionado proceso.
Para cumplir con las necesidades mencionadas, se plantea la utilizacin del
Mtodo gil de Desarrollo SCRUM, aplicado a la Implantacin de un Sistema
Informtico para la Administracin del Proceso Operativo en Recoleccin Masiva
De Informacin Con Tecnologa Mvil.
La ejecucin de este proyecto permitir a ASISTECOM Ca. Ltda., desarrollar e
implantar en corto tiempo un sistema informtico propio, establecer un marco de
trabajo eficiente para el desarrollo y posterior mantenimiento, optimizar la
utilizacin de recursos (Hardware, Software, Tecnologa Mvil), reducir los gastos
generados por mantenimiento de software y brindar un mejor y ms eficiente
servicio a sus clientes actuales y nuevos.
Los principales motivos que han llevado a la eleccin de SCRUM son:
Es uno de los mtodos de gestin de proyectos, de la denominados
filosofa gil, que permite un manejo apropiado de las expectativas del
cliente, basadas en resultados tangibles.

9

Es uno de los mtodos giles menos conocidos y utilizados en nuestro
medio, por lo que el presente trabajo puede resultar en un aporte
significativo al conocimiento del mismo.
Otro factor importante es la experiencia con que cuenta el responsable del
presente trabajo en la ejecucin de proyectos de desarrollo de software
utilizando una variacin la metodologa seleccionada.
1.3. Alcance
En este contexto, se establecen los aspectos que debe abarcar la ejecucin
del presente proyecto, as como los alcance del nuevo sistema informtico para
la Administracin del Proceso de Recoleccin Masiva de Informacin In Situ con
Tecnologa Mvil para la empresa ASISTECOM Ca. Ltda., esto es:
Estudio y aplicacin del mtodo gil SCRUM aplicado a la IMPLANTACIN
de un nuevo sistema informtico para ASISTECOM Ca. Ltda., el mismo que le
permita gestionar el proceso de recoleccin masiva de informacin in situ para
uno de sus principales clientes (EEQ Lectura de consumo elctrico).
Establecer SCRUM como el marco de trabajo oficial de ASISTECOM para el
desarrollo de nuevas funcionalidades y/o mantenimiento de la aplicacin, que
no se ha establecido como alcance de este proyecto.
Anlisis, desarrollo e implementacin del sistema informtico comprendido por:


10

Una Aplicacin de escritorio con los siguientes mdulos:
Mdulo de Administracin de Seguridad: Crear, eliminar, modificar
usuarios, equipos y perfiles para controlar el acceso a los diferentes
mdulos del sistema
Mdulo de Administracin de parmetros del Sistema: Crear, eliminar,
modificar variables que permitan parametrizar fcilmente aspectos
generales del sistema, como lo son el acceso a la base de datos,
repositorios para actualizaciones del sistema, direcciones de acceso al
sistema para dispositivos mviles, etc.
Mdulo de Gestin del Proceso de Recoleccin de Informacin Masiva
con Tecnologa Mvil: Cargar y procesar la informacin proporcionada y
requerida por el cliente de ASISTECOM. Generar los reportes
requeridos por ASISTECOM para control y seguimiento del proceso.
Una Aplicacin para dispositivos mviles, basados en Windows Mobile que
permita:
Llevar a cabo el proceso de recoleccin de informacin in situ con
dispositivos mviles.
Cargar y descargar de informacin desde y hacia los repositorios de
informacin de la empresa.
o Sincronizacin utilizando la interfaz USB de los equipos mviles.
o Sincronizacin en lnea, utilizando las redes de telefona celular.


11

Realizar las pruebas tcnicas y funcionales de la aplicacin, en base a las
caractersticas antes descritas, previo la implantacin en un ambiente de
produccin.
El nuevo sistema brindar todas las funcionalidades de la aplicacin que se utiliza
actualmente para la ejecucin del proceso, permitir gestionar no solo el proceso
en s, sino tambin los recursos utilizados (usuarios, equipos, etc.), optimizar la
utilizacin de recursos tecnolgicos con que cuenta la empresa y proporcionara
soluciones a las deficiencias identificadas en el sistema actual.
Finalmente el nuevo sistema informtico ser desarrollado en una arquitectura
distribuida, que brinde escalabilidad y permita la implementacin de nuevos
procesos y/o clientes no definidos como alcance de este proyecto.
1.4. Objetivos
1.4.1. Objetivo General:
Utilizar el Mtodo gil SCRUM, aplicado a la Implantacin de un Sistema
Informtico para el Proceso de RECOLECCIN MASIVA DE INFORMACIN IN
SITU CON TECNOLOGA MVIL.
1.4.2. Objetivos Especficos:
Revisar y analizar los conceptos relacionados a las metodologas de
desarrollo de software.
Analizar el mtodo SCRUM y su aporte a la ejecucin del presente
proyecto.

12

Analizar el proceso de Recoleccin de Informacin Masiva en la empresa
ASISTECOM CA. LTDA.
Disear la arquitectura a emplear en el Sistema Informtico para la
Administracin del Proceso Operativo en Recoleccin de Informacin
Masiva con Tecnologa Mvil.
Establecer SCRUM como el marco de trabajo para el desarrollo de la
aplicacin propuesta as como de futuras implementacin de
funcionalidades y/o mantenimiento de la misma.
Desarrollo, pruebas e implantacin del sistema Informtico propuesto,
basado en el mtodo SCRUM.


13

CAPTULO 2
2.1. Marco Terico
Este captulo tiene como objetivo, brindar una descripcin del marco terico
de referencia al mtodo gil de desarrollo de software SCRUM previo a la
ejecucin de un ejercicio prctico, aplicado a la elaboracin de un producto de
software utilizado en el proceso de RECOLECCIN MASIVA DE INFORMACIN
IN SITU CON TECNOLOGA MVIL.
En el mbito de la ingeniera de software existe un continuo debate entre los
partidarios de las metodologas tradicionales y aquellos que apoyan a las ideas
emanadas del Manifiesto gil
2
.
Por un lado, para muchos equipos de desarrollo el uso de metodologas
tradicionales resulta muy lejano a su forma de trabajo actual y la realidad de su
cartera de proyectos, considerando las dificultades asociadas a la inversin en
trminos de formacin y costos de herramientas utilizadas. Por otro lado estn las
caractersticas de los proyectos para los cuales las metodologas giles han sido
especialmente pensadas; aquellos proyectos en los cuales los equipos de
desarrollo son pequeos, de corto plazo, con requisitos voltiles y basados en
nuevas tecnologas.
Las metodologas giles estn especialmente orientadas a proyectos que
necesitan soluciones a medida, con una elevada simplificacin en trminos de
tiempo y recursos, sin dejar de lado el aseguramiento de la calidad del producto.

2
(Independent Signatories of The Manifesto for Agile Software Development)

14

Estas metodologas se centran en el factor humano y el producto software; es
decir, le dan mayor importancia al equipo de desarrollo, a la colaboracin del
cliente y al desarrollo incremental del software con iteraciones cortas (en tiempo).
2.2. Metodologas Tradicionales de Desarrollo de Software
Inicialmente el desarrollo de software se lo llevaba a cabo de una forma
totalmente artesanal. El crecimiento espectacular de la demanda de sistemas de
computacin cada vez ms y ms complejos, asociado a la inmadurez del propio
sector informtico y a la falta de mtodos y recursos, provoc lo que se llam la
crisis del software
3
entre los aos 1965 y 1985.
Durante esa poca muchos proyectos importantes superaban ampliamente los
presupuestos y fechas estimadas para su ejecucin, por lo que las perdidas iban
mucho ms all del mbito econmico.
La importancia adquirida por los sistemas de computacin dio lugar a una fuerte
necesidad de mejorar el proceso para llevar los proyectos de desarrollo a la meta
deseada.
Para resolver este problema fue necesario importar la concepcin y fundamentos
de metodologas existentes en otras reas y adaptarlas al desarrollo de software.
Esta adopcin llevo a dividir el proceso de desarrollo en etapas generalmente
secuenciales, lo que en algo ayudo en la latente necesidad de formalizar los
procesos de desarrollo de software.

3
F. L. Bauer, Primera conferencia de la tecnologa de dotacin lgica de la OTAN (Garmisch
1968)

15

Esta etapa de crisis fue superada no nicamente por la mejora en la gestin de
los proyectos sino tambin por los progresos que se estaban dando en los
procesos de diseo y metodologas de desarrollo.
La solucin definitiva al problema de la planificacin, previsin de costes y
aseguramiento de la calidad en el proceso de desarrollo de software est ligada
principalmente a la aparicin de herramientas, metodologas y tecnologas.
Entre las principales metodologas de este tipo se encuentra RUP y MSF, que
centran su atencin en llevar una documentacin exhaustiva de todo el proyecto y
el cumplimiento estricto de un plan de proyecto, definido todo esto, en la fase
inicial del proyecto.
Otras caractersticas importantes dentro de este enfoque son los altos costos de
implementar un cambio y las dificultades de aplicarlo en proyectos donde el
entorno es cambiante.
Las metodologas tradicionales (formales) se focalizan en la documentacin,
planificacin y procesos. (Plantillas, tcnicas de administracin, revisiones, etc.).
2.2.1. Principales metodologas Tradicionales
2.2.1.1. Rational Unified Process (RUP)
4

RUP provee un acercamiento disciplinado para asignar tareas y
responsabilidades dentro de una organizacin de desarrollo. Su objetivo es
asegurar la produccin de software de alta calidad que satisfaga los

4
RATIONA,31 de enero de 2012 <http://www.rational.com.ar/herramientas/rup.html>

16

requerimientos de los usuarios finales (respetando cronograma y presupuesto).
Fue desarrollado por Rational Software, y est integrado con toda la suite de
herramientas Rational. Puede ser adaptado y extendido para satisfacer las
necesidades de la organizacin que lo adopte. Es guiado por casos de uso,
centrado en la arquitectura y utiliza UML como lenguaje de notacin.

Figura 2. Rational Unified Process
Fuente: Adaptado de (INFORMATICA ADSI , 2010)
2.2.1.2. MICROSOFT SOLUTION FRAMEWORK (MSF)
5

MSF es un compendio de las mejores prcticas en cuanto a administracin
de proyectos se refiere. Ms que una metodologa rgida de administracin de
proyectos, MSF es una serie de modelos que puede adaptarse a cualquier
proyecto de tecnologa de informacin.

5
MICROSOFT, 31 de enero de 2012 <http://msdn.microsoft.com/es-
es/library/ms195024%28v=vs.80%29.aspx>

17

MSF divide a todo proyecto, separndolo en cinco fases principales:
Visin y Alcances.
Planificacin.
Desarrollo.
Estabilizacin.
Implantacin.

Figura 3. MICROSOFT SOLUTION FRAMEWORK
Fuente: Adaptado de (Arevalo)
2.3. Metodologas giles de Desarrollo de Software
2.3.1. Antecedentes
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, aparece el
trmino gil aplicado al desarrollo de software. En esta reunin participaron un
grupo de 17 expertos de la industria del software, incluyendo algunos de los
creadores o impulsores de las metodologas de software existentes a la fecha.

18

Su objetivo fue perfilar los valores y principios que deberan permitir a los equipos
de desarrollo, crear productos de software rpidamente y que estos equipos
fueran capaces de asimilar rpidamente lo cambios que puedan surgir a lo largo
del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de
software tradicionales, que como se mencion, estaban caracterizados por ser
rgidos y dirigidos por la documentacin que se genera en cada una de las
actividades desarrolladas.
Tras esta reunin se cre The Agile Alliance3, una organizacin, sin fines de
lucro, dedicada a promover los conceptos relacionados con el desarrollo gil de
software y ayudar a las organizaciones para que adopten dichos conceptos. El
punto de partida fue el Manifiesto gil
6
, un documento que resume la filosofa
gil.
2.3.2. El manifiesto gil
Los integrantes de la reunin resumieron los principios sobre los que se
basan los mtodos alternativos, en un documento denominado Manifiesto gil.
El manifiesto gil est fundamentado en los siguientes valores.
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y
las herramientas. La gente es el principal factor de xito de un proyecto
software. Es ms importante construir un buen equipo que construir el
entorno. Muchas veces se comete el error de construir primero el entorno y
esperar que el equipo se adapte automticamente. Es mejor crear el

6
(Independent Signatories of The Manifesto for Agile Software Development)

19

equipo y que ste configure su propio entorno de desarrollo en base a sus
necesidades.
Desarrollar software que funciona ms que conseguir una buena
documentacin. La regla a seguir es no producir documentos a menos que
sean necesarios de forma inmediata para tomar un decisin importante.
Estos documentos deben ser cortos y centrarse en lo fundamental.
La colaboracin con el cliente ms que la negociacin de un contrato. Se
propone que exista una interaccin constante entre el cliente y el equipo de
desarrollo. Esta colaboracin entre ambos ser la que marque la marcha
del proyecto y asegure su xito.
Responder a los cambios ms que seguir estrictamente un plan. La
habilidad de responder a los cambios que puedan surgir a los largo del
proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.)
determina tambin el xito o fracaso del mismo. Por lo tanto, la
planificacin no debe ser estricta sino flexible y abierta.
Los valores enumerados anteriormente inspiran los doce principios del manifiesto,
estos son:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas
entregas de software que le aporte un valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el
cliente tenga una ventaja competitiva.

20

III. Entregar frecuentemente software que funcione desde un par de semanas
a un par de meses, con el menor intervalo de tiempo posible entre
entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo
del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el
apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar
informacin dentro de un equipo de desarrollo.
VII. El software que funciona es la medida principal de progreso.
VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores,
desarrolladores y usuarios deberan ser capaces de mantener una paz
constante.
IX. La atencin continua a la calidad tcnica y al buen diseo mejora la
agilidad.
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos
organizados por s mismos.
XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser
ms efectivo, y segn esto ajusta su comportamiento.


21

2.3.3. Principales metodologas giles
Aunque los creadores e impulsores de las metodologas giles ms
populares han suscrito el manifiesto gil y coinciden con los principios enunciados
anteriormente, existen una gran variedad de metodologas basadas en estos
principios, cada una tiene caractersticas propias y enfatiza en algunos aspectos
especficos. A continuacin se resumen alunas metodologas giles. La mayora
de ellas han siendo utilizadas con xito en proyectos reales pero disponen de
poca difusin o reconocimiento.
2.3.3.1. SCRUM
7

Mtodo desarrollado por Ken Schwaber, Jeff Sutherland y Mike Beedle.
Define un marco para la gestin de proyectos, que se ha utilizado con xito
durante los ltimos 10 aos.
Est especialmente indicada para proyectos con un rpido cambio de requisitos.

Figura 4. SCRUM
Fuente: Adaptado de (Epidata Consulting)


7
CONTROLCHAOS ,31 de enero de 2012 <http://www.scrum.org/scrumguides/>

22

Sus principales caractersticas se pueden resumir en:
El desarrollo de software se realiza mediante iteraciones, denominadas
Sprints, con una duracin variable de hasta 30 das. El resultado de cada
sprint es un incremento ejecutable que se muestra al cliente.
La segunda caracterstica importante son las reuniones a lo largo proyecto,
entre ellas destaca la reunin diaria de 15minutos del equipo de desarrollo
para coordinacin e integracin.
2.3.3.2. ExtremeProgramming
8

La Programacin Extrema (del ingls ExtremeProgramming) es uno de los
llamados procesos o metodologas giles de desarrollo de software. Consiste en
un conjunto de prcticas que a lo largo de los aos han demostrado ser las
mejores prcticas de desarrollo de software, llevadas al extremo, fundamentadas
en los valores de las metodologas giles.

Figura 5. Extreme Programming
Fuente: Adaptado de (Sanchez, 2004)

8
PROGRAMACIONEXTREMA,31 de enero de 2012 <http://www.programacionextrema.org>

23


2.3.3.3. Crystal Methodologies
9

Se trata de un conjunto de metodologas para el desarrollo de software
caracterizadas por estar centradas en las personas que componen el equipo y la
reduccin al mximo del nmero de artefactos producidos. Han sido desarrolladas
por AlistairCockburn.
El desarrollo de software se considera un juego cooperativo de invencin y
comunicacin, limitado por los recursos a utilizar. El equipo de desarrollo es un
factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y
destrezas, as como tener polticas de trabajo en equipo bien definidos. Estas
polticas dependern del tamao del equipo, establecindose una clasificacin por
colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50
miembros).

Figura 6. Crystal Methodologies
Fuente: Adaptado de (Wikiversity)


9
CRYSTALMETHODOLOGIES,31 de enero de 2012 <http://ww16.crystalmethodologies.org/>

24

2.3.3.4. Dynamic Systems Development Method (DSDM)
10

Define el marco para desarrollar un proceso de produccin de software. Nace
en 1994 con el objetivo de crear una metodologa RAD unificada. Sus principales
caractersticas son:
Es un proceso iterativo e incremental y el equipo de desarrollo y el usuario
trabajan juntos.
Propone cinco fases: estudio de viabilidad, estudio del negocio, modelado
funcional, diseo y construccin, y finalmente implementacin.
Las tres ltimas son iterativas, adems de existir realimentacin a todas las
fases.

Figura 7. Dynamic Systems Development Method
Fuente: Adaptado de (Agile Certification)


10
DSDM,31 de enero de 2012 <www.dsdm.org>

25

2.3.3.5. Feature -DrivenDevelopment (FDD)
11

Define un proceso iterativo que consta de 5 pasos. Las iteraciones son
cortas (hasta 2 semanas). Se centra en las fases de diseo e implementacin del
sistema partiendo de una lista de caractersticas que debe reunir el software. Sus
impulsores son Jeff De Luca y Peter Coad.

Figura 8. Feature -DrivenDevelopment
Fuente: Adaptado de (Texnovate Solutions Limited)

2.3.3.6. Lean Development(LD)
12

Definida por Bob Charette.s a partir de su experiencia en proyectos con la
industria japonesa del automvil en los aos 80 y utilizada en numerosos
proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran
riesgos, pero si se manejan adecuadamente se pueden convertir en
oportunidades que mejoren la productividad del cliente. Su principal caracterstica
es introducir un mecanismo para implementar dichos cambios.

11
FEATUREDRIVENDEVELOPMENT,31 de enero de
2012<http://www.featuredrivendevelopment.com/>
12
POPPENDIECK,31 de enero de 2012 <http://www.poppendieck.com/>

26


Figura 9. Lean Development
Fuente: Adaptado de (Net Objectives)
2.4. Metodologas giles vs. Tradicionales
En el contexto del desarrollo de software, la necesidad de que los
proyectos concluyan exitosamente y obtener un producto de gran valor para el
cliente, se generan grandes cambios en las metodologas adoptadas por los
equipos para cumplir sus objetivos, puesto que, unas se adaptan mejor que otras,
al contexto del proyecto, brindando mejores ventajas.
El xito del proyecto y la calidad del producto dependen en gran parte de la
metodologa escogida por el equipo, ya sea tradicional o gil, donde los equipos
maximicen su potencial, aumenten la calidad del producto con los recursos y
tiempos establecidos.
El siguiente cuadro recoge las principales diferencias respecto del proceso,
contexto de equipo y organizacin que es ms favorable a cada una de estas
filosofas de desarrollo de software.

27

Tabla 3. Comparacin entre metodologas giles y tradicionales
Metodologas giles Metodologas Tradicionales
Basadas en heursticas aplicadas en
la prcticas de produccin de cdigo.
Basadas en estndares seguidos por el entorno
de desarrollo.
Especialmente preparados para
adaptarse a cambios durante el
proyecto
Resistencia a los cambios improvistos.
Impuestas internamente (por el
equipo)
Impuestas externamente
Proceso menos controlado, con pocos
principios
Proceso mucho ms controlado, con numerosas
polticas/normas
No se rige a un contrato tradicional o
al menos es bastante flexible
Se rige estrictamente a un contrato prefijado
El cliente interacta con el equipo de
desarrollo
El cliente es parte del equipo de desarrollo
mediante reuniones
Grupos pequeos (10 integrantes
mximo) y trabajando en el mismo
sitio
Grupos grandes y posiblemente distribuidos
Pocos artefactos Varios artefactos
Pocos roles Varios roles
Menos nfasis en la arquitectura del
software
La arquitectura del software es esencial y se
expresa mediante modelos
Ms utilizados en proyectos medianos
y pequeos.
Ms utilizado es proyectos grandes
Nota. Fuente: Adaptado de (Xelphos Group)

28

2.5. SCRUM
2.5.1. Introduccin
SCRUM es un mtodo gil de gestin de proyectos cuyo objetivo principal
es elevar al mximo la productividad de equipo de desarrollo. Reduce al mximo
las actividades no orientadas a producir software funcional y produce resultados
en periodos cortos de tiempo. Como mtodo, enfatiza valores y prcticas de
gestin, sin pronunciarse sobre requerimientos, prcticas de desarrollo,
implementacin y dems cuestiones tcnicas. Ms bien delega completamente al
equipo la responsabilidad de decidir la mejor manera de trabajar para ser lo ms
productivos posibles.
La palabra SCRUM procede de la terminologa del juego de rugby, donde SCRUM
se define como el acto de preparar el avance del equipo en unidad pasando la
pelota entre uno y otro jugador.
SCRUM fue desarrollado por Jeff Sutherland y elaborado ms formalmente por
Ken Schwaber. Poco despus Sutherland y Schwaber se unieron para refinar y
extender la metodologa SCRUM y ha llegado a ser conocida como una
herramienta de hiperproductividad. Schwaber se dio cuenta de que un proceso
necesita aceptar el cambio, en lugar de esperar predictibilidad, esto enfocado en
el hecho de que procesos definidos y repetibles slo funcionan para atacar
problemas definidos y repetibles con gente definida y repetible en ambientes
definidos y repetibles. Tomar el cambio como una forma de entregar al final del
desarrollo algo ms cercano a la verdadera necesidad del Cliente fue entonces su
solucin.

29

SCRUM no se trata nicamente de un mtodo para desarrollo de software, sino
que puede ser aplicado tericamente a cualquier contexto en donde un grupo de
personas (equipo de trabajo) necesita trabajar junta para lograr una meta comn.
Como metodologa para desarrollo de software, se basa en los principios giles
mencionados anteriormente, pero es necesario complementar el mtodo SCRUM
con otros mtodos para su implementacin en el mbito de desarrollo de
software.
2.5.2. La Esencia De SCRUM
Ms que una metodologa de desarrollo, SCRUM es una herramienta para
gestionar proyectos.
Est basado en el hecho de que el trabajo es realizado por equipos auto-
organizado y auto-dirigidos, logrando motivacin, responsabilidad y
compromiso.
Es un proceso constructivo, iterativo e incremental donde las iteraciones
tienen una duracin fija.
Contiene definicin de roles, prcticas y productos de trabajo escritas de
forma simple y soportada en un conjunto de valores y principios (Mtodos
Agiles).


30

2.5.3. Elementos del SCRUM
Roles
o Product Owner (Propietario del producto)
o SCRUM Master
o Team (Equipo)
Poda de requerimientos
Product Backlog
Sprint
o Planificacin
o Sprint Backlog
o SCRUM
o Estimaciones
o Builds continuos
o Revisin del Sprint
o Reunin retrospective
Valores
o Foco, comunicacin, respeto y coraje.

31


Figura 10. Elementos del SCRUM
Fuente: Adaptado de (Gestar)






32

2.5.3.1. Roles
El nombre de los miembros del equipo y los externos se deriva de una tpica
fbula agilista: un cerdo y una gallina discutan qu nombre ponerle a un nuevo
restaurante; la gallina propuso Jamn y Huevos. No, gracias, respondi el
cerdo, Yo estar comprometido, mientras t slo implicada.
SCRUM diferencia claramente entre estos dos grupos para garantizar que
quienes tienen la responsabilidad tienen tambin la autoridad necesaria para
poder lograr el xito, y que quienes no tienen la responsabilidad, los observadores
externos, no produzcan interferencias innecesarias.
Tabla 4. Roles del SCRUM
Comprometido en el
proyecto
Implicados en el
proyecto
-Dueo del producto
-Equipo
-SCRUM Master
-Marketing
-Comercial
-Etc.
SCRUM tiene una estructura muy simple. Todas las responsabilidades del
proyecto se reparten en 3 roles:
2.5.3.1.1. Product owner (Dueo del producto)
Representa a todos los interesados en el producto final. Es el
responsable oficial del proyecto, gestin, control y visibilidad de la lista
de acumulacin o lista de retraso del producto (Product Backlog). Toma

33

las decisiones finales de las tareas asignadas al registro y convierte sus
elementos en rasgos a desarrollar.
Sus reas de responsabilidad son:
Financiacin del proyecto
Requisitos del sistema
Retorno de la inversin del proyecto
Lanzamiento del proyecto
2.5.3.1.2. SCRUM Master (Lder del proyecto)
Responsable del proceso SCRUM, de cumplir la meta y resolver los
problemas. As como tambin, de asegurarse que el proyecto se lleve a
cabo de acuerdo con las prcticas, valores y reglas de SCRUM y que
progrese segn lo previsto.
Interacta con el cliente y el equipo. Coordina los encuentros diarios, y
se encarga de eliminar eventuales obstculos. Debe ser miembro del
equipo y trabajar a la par.
2.5.3.1.3. Team (Equipo)
Responsable de transformar el Backlog de la iteracin en un incremento
de la funcionalidad del software. Tiene autoridad para reorganizarse y
definir las acciones necesarias o sugerir remocin de impedimentos.


34

La dimensin del equipo total de SCRUM no debera ser superior a
veinte. El nmero ideal es diez, ms o menos dos. Si hay ms, lo ms
recomendable es formar varios equipos. No hay una tcnica oficial para
coordinar equipos mltiples, pero se han documentado experiencias de
hasta 800 miembros, divididos en SCRUMs de SCRUMs, definiendo un
equipo central que se encarga de la coordinacin, las pruebas cruzadas
y la rotacin de los miembros.
2.5.3.2. Poda de requerimientos
La poda de requerimientos es una buena prctica implcita en modelos
giles, y consiste en hacer lo que el cliente realmente desea, no ms.
La primera actividad en un proyecto manejado con SCRUM es armar una lista
exhaustiva de los requerimientos originales del sistema. Posteriormente se realiza
una revisin para evaluar qu requerimientos son realmente necesarios, cules
pueden posponerse y cules eliminarse. Para ello debe identificarse un
representante con capacidad de decisin, priorizar los requerimientos en base a
su importancia y acordar cules son los prioritarios para la fecha de entrega.
2.5.3.3. Product Backlog
Con los requerimientos priorizados y podados se arma el Backlog de
Producto. Este es una forma de registrar y organizar el trabajo pendiente para el
producto (actividades y requerimientos).

35

Es un documento dinmico que incorpora constantemente las necesidades del
sistema. Por lo tanto, nunca llega a ser una lista completa y definitiva. Se
mantiene durante todo el ciclo de vida y es responsabilidad del Product Owner.
2.5.3.4. Sprint
SCRUM est basado en el control emprico de procesos. Se utiliza cuando
la capacidad de prediccin es vaga, la incertidumbre alta o el proceso es
demasiado complejo para ser modelado y definido.
En el enfoque emprico de control de procesos se establecen reglas simples y se
crea una disciplina de inspeccin frecuente para adaptarse rpidamente a
situaciones no previstas o problemas.
Un Sprint es el periodo de tiempo durante el que se desarrolla un incremento de
funcionalidad. Constituye el ncleo de SCRUM, que divide de esta forma el
desarrollo de un proyecto en un conjunto de pequeas carreras.

Figura 11. SPRINT
Fuente: Adaptado de (Epidata Consulting)


36

Aspectos a tener en cuenta en un Sprint:
Duracin mxima del Sprint: 30 das, recomendada 15 das.
Durante el Sprint no se puede modificar el trabajo que se ha acordado en el
Backlog.
Slo es posible cambiar el curso de un Sprint, abortndolo, y slo lo puede
hacer el SCRUM Master si decide que no es viable por alguna de las
razones siguientes:
o La tecnologa acordada no funciona.
o Las circunstancias del negocio han cambiado.
o El equipo ha tenido interferencias.
2.5.3.4.1. Planificacin
Se planifica en detalle el trabajo al inicio de cada Sprint asumiendo que los
objetivos no van a cambiar durante el mismo. De esta manera se atena el
riesgo.
Aspectos a tener en cuenta sobre la planificacin de un Sprint:
Una determinacin general de alcance, frecuentemente basada en
una EDT (Estructura de Divisin del Trabajo).
Estimaciones de esfuerzo de alto nivel realizadas durante la etapa
de concepcin del proyecto.
Esfuerzo dedicado a labores de soporte o de preparacin de los
ambientes requeridos por el proyecto.
Esfuerzo asociados a las reuniones diarias, de planificacin y de
revisin.

37

Requerimientos de recursos de infraestructura o logsticos
(mquinas, redes, licencias, papel, pizarras, etc.).
Habilidades presentes y necesarias en el equipo.
Restricciones asociadas al conocimiento del negocio, la tecnologa o
externas (legales, reglamentarias, estndares, etc.).
El rol del SCRUM Master durante la planificacin es:
Dirigir la planificacin.
Facilitar acuerdos entre el equipo y el Product Owner del proyecto.
Registrar problemas y riesgos detectados durante la planificacin.
Registrar las tareas, asignaciones y estimaciones.
Iniciar el Backlog del Sprint.
2.5.3.4.2. Sprint Backlog
Trabajo o tareas determinadas por el equipo para realizar en un Sprint.
Tareas a convertir en producto funcional.
Las tareas se estiman en una duracin entre 1 y 20 horas de
trabajo. Las de mayor duracin deben intentar descomponerse
en sub-tareas en el rango de tiempo indicado.
La estimacin como el avance de las tareas se actualiza da a
da.

38

2.5.3.4.3. SCRUM diario
SCRUM asume que el proceso es complejo y que es necesario
inspeccionarlo frecuentemente, por eso se realiza una reunin diaria de
seguimiento. El encuentro diario impide caer en el dilema sealado por
Fred Brooks: Cmo es que un proyecto puede atrasarse un ao? Un
da a la vez.
El foco de la reunin es determinar el avance en las tareas y detectar
problemas que estn haciendo lento el progreso del equipo o que
eventualmente impidan a un equipo cumplir con la meta del Sprint. La
idea es que ningn problema quede sin resolver o, por lo menos, sin
iniciar alguna accin de respuesta dentro de las 24 horas despus de
su deteccin.
La reunin es adems un espacio definido para que cada miembro del
equipo comunique a los dems el estado de su trabajo.
El rol del SCRUM Master durante el SCRUM es:
Dirigir la reunin y mantiene el foco.
Hacer preguntas para aclarar dudas.
Registrar (documentar) los problemas para su resolucin
despus de la reunin.
Asegura que los miembros cuenten con el ambiente adecuado
para la reunin.


39

2.5.3.4.4. Estimaciones
Las estimaciones se realizan por primera vez en la reunin de
planificacin al inicio del Sprint. Luego las tareas se re-estiman todos
los das y se registran sus cambios en el Backlog del Sprint; esta
actividad puede ser realizada inmediatamente antes o despus del
SCRUM diario.
2.5.3.4.5. Builds continuos y pruebas bsicas
La estrategia que generalmente se utiliza es la de Builds continuos y
prueba bsica para la funcionalidad del sistema consiste en:
Los programadores desarrollan segn el Backlog del Sprint, y al
finalizar, notifican al integrador.
El integrador toma el cdigo y lo integra con el resto del
producto.
Se compila el software y se prueba superficialmente el producto,
para verificar la estabilidad de la versin.
Si se encuentran problemas se devuelve al desarrollador.
Si no se han encontrado errores se notifica al equipo que hay
una nueva versin estable del cdigo para usar como base.

Figura 12. Builds continuos

40

2.5.3.4.6. Revisin del Sprint
El objetivo de la reunin de revisin es presentar el producto o porcin
del producto desarrollada por el equipo a los usuarios. La reunin se
utiliza para detectar inconformidades mayores que se vuelven
elementos del Backlog de Producto y que eventualmente se resuelven
en el siguiente Sprint.
A la reunin asisten el equipo, el SCRUM Master, el Product Owner y
todas las personas implicadas en el proyecto. Esta revisin se convierte
en un demo del producto con las nuevas funcionalidades desarrolladas
durante el Sprint.
2.5.3.4.7. Reunin retrospectiva
SCRUM involucra el concepto de mejora continua a travs de las
reuniones de retrospeccin. Las reuniones buscan detectar los puntos
positivos y negativos del Sprint para generar propuestas de mejora para
futuros Sprints.
Las reuniones de retrospeccin son el concentrador del aprendizaje
organizacional sobre el SCRUM. Los puntos positivos y negativos se
registran y se definen tems de accin para cada uno. Los tems de
accin definidos se toman en cuenta en los siguientes Sprints.
A esta reunin acuden el equipo, el SCRUM Master, y opcionalmente el
Product Owner del Producto.

41

2.5.3.5. Valores
2.5.3.5.1. Foco
Los individuos y sus interacciones son ms importantes que el proceso
o las herramientas. El recurso humano es el principal factor de xito de
un proyecto de software.
2.5.3.5.2. Comunicacin
SCRUM pone en comunicacin directa y continua a clientes y
desarrolladores. El cliente se integra en el equipo para establecer
prioridades y resolver dudas. De esta forma ve el avance da a da, y es
posible ajustar la agenda y las funcionalidades de forma consecuente.
2.5.3.5.3. Respeto
SCRUM diferencia claramente entre dos grupos para garantiza que
quienes tienen la responsabilidad tienen tambin la autoridad necesaria
para poder lograr el xito (cerdos), y que quienes no tienen la
responsabilidad, los observadores externos (gallinas), no produzca
interferencias innecesarias.
2.5.3.5.4. Coraje
El coraje implica saber tomar decisiones difciles. Reparar un error
cuando se detecta. Mejorar el cdigo siempre que el feedback y las
sucesivas iteraciones se manifiesten susceptibles de mejora.


42

CAPTULO 3
3.1. Metodologa
Se entiende por metodologa a la coleccin de documentacin formal
referente a los procesos, polticas y procedimientos que intervienen en las
diferentes etapas de la ejecucin de un proceso.
13

Una metodologa de desarrollo de software se refiere a un marco de trabajo
utilizado para estructurar, planear y controlar el proceso de desarrollo en sistemas
de informacin. Este marco de trabajo debe ser enfocado al proceso de desarrollo
de software con la utilizacin de herramientas, modelos y mtodos que garanticen
un producto de calidad.
La finalidad de una metodologa de desarrollo es garantizar la eficacia (cumplir los
requisitos) y la eficiencia (optimizar recursos) en el proceso de generacin de
software.
Una metodologa puede seguir uno o varios modelos de ciclo de vida del software
que indican qu es lo que se obtendr a lo largo del desarrollo del proyecto,
durante este desarrollo, la metodologa indica cmo hay que obtener los distintos
productos parciales y finales.
La esencia de cualquier metodologa de desarrollo es la elaboracin de
documentos escritos que detallan cada etapa del ciclo de vida de desarrollo.

13
Blanco, S. (s.f.). Marble Station. Recuperado el 15 de 03 de 2012, de
http://www.marblestation.com/?p=644


43

3.2. Desarrollo iterativo e incremental
En un desarrollo iterativo e incremental un proyecto de desarrollo se
planifica en diversos bloques temporales, en el caso de SCRUM estos periodos
de tiempo, denominados iteraciones o Sprints tienen una duracin recomendada
de entre dos a cuatro semanas.
Cada iteracin se puede entender como un pequeo proyecto individual: en cada
iteracin se repite un proceso de trabajo similar iterativo para proporcionar un
resultado completo sobre el producto final, para que el cliente pueda obtener los
beneficios del proyecto de forma incremental. Para ello, es recomendable que
cada requisito se complete en una nica iteracin: el equipo debe realizar todas
las tareas necesarias para completarlo (incluyendo pruebas y documentacin) y
que est preparado para ser entregado al cliente con el mnimo esfuerzo
necesario. De esta manera no se deja para el final del proyecto ninguna actividad
relacionada con la entrega de requisitos.
Para la ejecucin del presente proyecto, se ha propuesto un proceso iterativo e
incremental. Iterativo para garantizar la realimentacin de informacin y de
requisitos una vez iniciado el desarrollo, as como la validacin continua del
sistema. Esto permite que cada iteracin contemple ciclos de desarrollo
completos, cortos y que permitan obtener rpidamente una versin de software
con mejoras sobre las versiones anteriores. Incremental en el sentido de aadir
capacidades y funcionalidades al software de acuerdo a la planificacin inicial;
con el propsito de obtener el sistema final tras la realizacin de diferentes ciclos.
Es proceso permite realizar entregas al cliente de forma rpida y gil.

44

La estrategia de desarrollo propuesta permite a la vez enfocarse en las
necesidades de los usuarios, involucrndolos con las entregas de versiones
estables e instndolos a identificar sus prioridades en cada etapa del proyecto.
3.3. Etapas Del Proceso De Desarrollo
Las etapas de desarrollo de software son un reflejo del proceso que se
sigue a la hora de resolver cualquier tipo de problema. Ya en 1945, mucho antes
de que existiese la Ingeniera del Software, el matemtico George Polya describi
este proceso en su libro How to solve it seguramente el primero que describe la
utilizacin de tcnicas heursticas en la resolucin de problemas. Bsicamente,
resolver un problema requiere:
Comprender el problema (anlisis).
Plantear una posible solucin, considerando soluciones alternativas
(diseo).
Llevar a cabo la solucin planteada (implementacin).
Comprobar que el resultado obtenido es correcto (pruebas).
En este sentido, cualquier sistema de informacin pasa por una serie de fases a lo
largo de su vida. Su ciclo de vida comprende una serie de etapas entre las que se
encuentran las siguientes:
Planificacin
Anlisis

45

Diseo
Implementacin y Pruebas
Instalacin o despliegue
Uso y mantenimiento
Para cada una de las fases del ciclo de vida de un del desarrollo de software se
han propuesto prcticas tiles, entendiendo por prcticas aquellos conceptos,
principios, mtodos y herramientas que facilitan la consecucin de los objetivos de
cada etapa.
3.3.1. Planificacin
Antes de iniciar un proyecto de desarrollo de software, es necesario realizar
una serie de tareas previas, las mismas que influirn decisivamente en la
finalizacin exitosa del proyecto. Estas tareas normalmente no estn sujetas a
plazos. Las tareas que se realizarn esta fase inicial del proyecto incluyen
actividades tales como la determinacin del mbito del proyecto, la realizacin de
un estudio de viabilidad, una estimacin del coste del proyecto, su planificacin
temporal y la asignacin de recursos a las distintas etapas del proyecto .
Objetivo: Definir el proyecto propiamente dicho.
Tareas: Relevamiento preliminar de los procesos del negocio y definicin
de actividades, definicin del alcance, estimacin de tiempos, definicin de
recursos, estimacin de costos.

46

Entregables: Documento de definicin del proyecto o del Sprint.
3.3.2. Anlisis
Antes de iniciar la etapa de construccin es necesario conocer exactamente lo
que tiene que hacer el sistema. La etapa de anlisis en el ciclo de vida del
software corresponde al proceso mediante el cual se intenta descubrir qu es lo
que realmente se necesita y se llega a una comprensin adecuada de los
requerimientos del sistema (las caractersticas que el sistema debe poseer).
Objetivo: Obtener todas las definiciones y especificaciones funcionales
para poder llevar adelante las fases de Diseo y Construccin. Es una
etapa clave ya que el alcance y las caractersticas de la solucin quedan
acordados, lo cual permite mitigar los principales riesgos de un proyecto.
Tareas: Afianzamiento de las definiciones funcionales, definicin de los
requisitos a travs de casos de uso, planificacin de las etapas posteriores
y ajuste de los tiempos preestablecidos.
Entregable: Documento de alcance, casos de uso y sus respectivas
descripciones.
3.3.3. Diseo
Mientras que los modelos utilizados en la etapa de anlisis representan los
requisitos del usuario desde distintos puntos de vista (Qu hacer?), los modelos
que se utilizan en la fase de diseo representan las caractersticas del sistema
que permitirn implementarlo de forma efectiva (Cmo Hacerlo?).

47

Un software bien diseado debe exhibir determinadas caractersticas. Su diseo
debera ser modular en vez de monoltico. Sus mdulos deberan ser cohesivos
(encargarse de una tarea concreta y slo de una) y estar dbilmente acoplados
entre s (para facilitar el mantenimiento del sistema). Cada mdulo debera ofrecer
a los dems unos interfaces bien definidos. Por ltimo, debe ser posible relacionar
las decisiones de diseo tomadas con los requerimientos del sistema que las
ocasionaron.
Objetivo: Generar el modelo de datos para que la solucin cumpla con los
requerimientos definidos. El diseo generado deber contemplar las
posibles modificaciones futuras, crecimiento de la solucin, mayor carga e
incorporacin de nuevas funcionalidades.
Tareas: Diagrama Entidad Relacin (DER), diseo de las interfaces de
usuario, diseo de las integraciones a realizar. Durante esta etapa tambin
se realizan pruebas para puntos crticos del proyecto.
Entregables: Entre los entregables tpicos de esta etapa se encuentran:
DER, esqueleto del software armado, gua de diseo, diseo de la
infraestructura, y la planificacin ajustada con la evolucin y avances
obtenidos.
3.3.4. Construccin y Pruebas
Una vez identificadas las funciones que debe desempear el sistema de
informacin (anlisis) y decidido cmo organizar sus distintos componentes
(diseo), es momento de pasar a la etapa de implementacin. Antes de iniciar la
codificacin o crear una tabla en nuestra base de datos es fundamental haber

48

comprendido bien el problema que se pretende resolver y haber aplicado
principios bsicos de diseo que permitan construir un sistema de informacin de
calidad.
Para la fase de implementacin es necesario seleccionar las herramientas
adecuadas, un entorno de desarrollo que facilite el trabajo y un lenguaje de
programacin apropiado para el tipo de sistema a construir. La eleccin de estas
herramientas depender en gran parte de las decisiones de diseo que se han
tomado hasta el momento y del entorno en el que el sistema deber funcionar.
Durante la etapa de construccin se puede iniciar tambin la etapa de pruebas
que tiene como objetivo detectar los errores que se hayan podido cometer tanto
durante la codificacin como en las dems etapas anteriores. El propsito, es
hacerlo antes de que el usuario final del sistema realice sus pruebas de
funcionamiento.
La etapa de pruebas puede adaptar distintas formas, en funcin del contexto y de
la fase en que se encuentre el proyecto, estas pueden ser:
Pruebas de unidad: sirven para comprobar el correcto
funcionamiento de un componente concreto de nuestro sistema.
Es este tipo de pruebas, buscar situaciones que expongan las
limitaciones de la implementacin del componente, en estas
pruebas el componente puede ser tratando como una caja negra
("pruebas de caja negra") o con un anlisis de su estructura
interna ("pruebas de caja blanca"). Resulta recomendable que,
conforme se aaden nuevas funcionalidades a la aplicacin, se

49

creen nuevos tests con los cuales medir el progreso; tambin es
importante repetir los test antiguos para comprobar que lo que
antes funcionaba sigue hacindolo.
Pruebas de integracin: son las que se realizan cuando se van
juntando los componentes que conforman el sistema y sirven
para detectar errores en sus interfaces.
Pruebas Alfa: Una vez "finalizado" el sistema, los responsables
del desarrollo realizan pruebas desde el punto de vista de un
usuario final, este tipo de pruebas pueden ayudar principalmente
a pulir aspectos de la interfaz de usuario del sistema y
validaciones que pudieron haberse pasado por alto durante la
codificacin.
Pruebas beta: Cuando el sistema no es un producto a medida,
sino que se vender como un producto en el mercado, se deben
realizar estas pruebas, que sern ejecutadas por usuarios finales
del sistema (clientes potenciales) ajenos al equipo de desarrollo.
En el caso del presente proyecto, este tipo de pruebas no aplica.
Pruebas de Aceptacin: En sistemas a medida, estas pruebas
son realizadas por los usuarios finales y si se supera con xito,
marcar oficialmente el final del proceso de desarrollo.
Objetivo: Construir la solucin del Release (Sprint), cumpliendo con las
definiciones y especificaciones de los documentos de alcance.

50

Generalmente es la etapa de mayor duracin y con mayor dinmica de
trabajo.
Tareas: Programacin y desarrollo de todos los componentes que brinden
las funcionalidades requeridas. Implementacin de las estructuras de
datos, y sus procedimientos, elaboracin de documentacin tcnica y
ajustes funcionales, implementacin de las integraciones y todas las
actividades necesarias para poner en marcha la solucin. En esta etapa se
realizarn las pruebas descritas anteriormente.
Entregables: El entregable principal es el incremento de software
funcionando.
Pruebas de software basado en Modelos
Las pruebas basadas en modelos son definidas como las pruebas de software
donde los casos de pruebas son derivados de un modelo que describe algunos o
todos los aspectos del sistema a probar. El sistema a probar puede ser tan simple
como un mtodo o una clase, o tan complejo como un sistema completo. Para
este tipo de pruebas, un modelo proporciona una descripcin del comportamiento
del sistema puesto a prueba. Esta descripcin es utilizada para determinar si el
sistema bajo prueba se ajusta las propiedades descritas en el modelo.
Existen varios modelos utilizados para el proceso de pruebas, de los cuales se
puede destacar los ilustrados en las figuras 13, 14 y 15.

51


Figura 13.Modelo V 14

Figura 14.El modelo W
15




14
( Zenteno, A. H. (2008). Mtodo de pruebas de sistema basado en modelos navegacionales en
un contexto MDWE. Recuperado el 15 de 03 de 2012, de
www.lsi.us.es/docs/doctorado/.../MemoInvestigArturoHTorres.pdf

15
Zenteno, A. H. (2008). Mtodo de pruebas de sistema basado en modelos navegacionales en un
contexto MDWE. Recuperado el 15 de 03 de 2012, de
www.lsi.us.es/docs/doctorado/.../MemoInvestigArturoHTorres.pdf

52


Figura 15.Modelo de Pruebas Orientada a Objetos para el Ciclo de Vida Completo.
16


El Modelo de la Figura 15, es un modelo muy completo, que se enfoca no
nicamente en la etapa de construccin, sino que, analiza todas las etapas de
ciclo de vida del software, es por ello que se ha decidido utilizar el mencionado
modelo; sin embargo, para el presente proyecto las pruebas sern enfocaran
nicamente para las fases de de codificacin, pruebas del sistema y pruebas de
usuarios. Los modelos utilizados en la etapa de anlisis han sido probados y se
encuentran actualmente implementados en los procesos operativos de
ASISTECOM, por tanto no sern sometidos a pruebas. As mismo los modelos
utilizados en la etapa de diseo, son modelos estndar, por lo que no necesitan
ser analizados ni probados nuevamente.
Las tcnicas de pruebas utilizadas en el modelo seleccionado son las descritas
en la Tabla 5.Tcnicas de pruebas.

16
(Ambler, 2004)

53

Las pruebas utilizadas dependern de las funcionalidades de componente a
probar y estas pueden variar entre los distintos mdulos del sistema;
Tabla 5.Tcnicas de pruebas
Tcnica Descripcin
Prueba de Caja-Negra
Centrada en un estudiado desde el punto de vista de las entradas que
recibe y las salidas que produce, sin tener en cuenta su funcionamiento
interno.
Prueba de Valores-
Frontera
Centrada en probar situaciones extremas o inusuales que el sistema
debe ser capaz de manejar.
Prueba de Clases
Es el acto de asegurar que una clase y todas sus instancias cumplen
con el comportamiento definido.
Prueba de Integracin
de Clases
Es el acto de asegurar que las clases, y sus instancias, conforman un
software que cumple con el comportamiento definido.
Revisin de Cdigo
Una forma de revisin tcnica en la que el entregable que se revisa en
el cdigo fuente.
Prueba de Componente
Es el acto de validar que un componente funciona tal como est
definido.
Prueba de Cubrimiento
Es el acto de asegurar que toda lnea de cdigo es ejercita al menos
una vez.
Revisin de Diseo
Una revisin tcnica en la cual se inspecciona un modelo de diseo.

Prueba de Regresin
de Herencia
Es el acto de ejecutar casos de prueba de las sper clases, tanto de
forma directa como indirecta, en una subclase especifica.
Prueba de Integracin
Consiste en realizar pruebas para verificar que un gran conjunto de
partes del software funcionan juntas.
Prueba de Mtodo
Consiste en realizar pruebas para verificar que un mtodo (funcin
miembro) funciona tal como est definido.
Revisin de Modelos
Un tipo de inspeccin, que puede ser desde un revisin tcnica formal
hasta un recorrido informal, realizado por personas diferentes a las que
estuvieron directamente involucradas en el desarrollo del modelo.
Prueba de Caminos
Es el acto de asegurar que todos los caminos lgicos en el cdigo se
ejercitan al menos una vez.

54

Tcnica Descripcin
Revisin de Prototipos
Es un proceso mediante el cual los usuarios trabajan a travs de una
coleccin de casos de uso, utilizando un prototipo como si fuera el
sistema real. El objetivo principal es probar si el diseo del prototipo
satisface las necesidades de esos usuarios.
Demostrar con el
cdigo
La mejor forma de determinar si un modelo realmente refleja lo que se
necesita, o lo que se debe construir, es construyendo software basado
en el modelo para mostrar que el modelo est bien
Prueba de Regresin
El acto de asegurar que los comportamientos previamente probados
todava trabajan como se espera luego que se han realizado cambios a
la aplicacin.
Prueba de Stress
El acto de asegurar que el sistema funciona como se espera bajo
grandes volmenes de transacciones, usuarios, carga y dems.
Revisin Tcnica
Una tcnica de aseguramiento de la calidad en la cual el diseo de tu
aplicacin es revisado de forma exhaustiva por un grupo de tus
compaeros. Una revisin tpicamente se enfoca en la precisin,
calidad, facilidad de uso y completitud. A este proceso usualmente se
le llama recorrido, inspeccin, o revisin de compaeros.
Prueba de Escenarios
de Uso
Una tcnica de prueba en la cual una o ms personas validan un
modelo siguiendo la lgica de los escenarios de uso.
Prueba de Interfaz de
Usuario
Consiste en probar la interfaz de usuario para garantizar que cumple
los estndares y requerimientos definidos. Usualmente se refiere a la
prueba de interfaz de usuario grfica.
Prueba de Caja-Blanca
Centrada en los detalles procedimentales del software, por lo que est
fuertemente ligado al cdigo fuente.
Nota: Las tcnicas utilizadas para probar el presente sistema dependern del mdulo y los
componentes a probar.
17



17
Ambler, S. W. (04 de 2004). Ambysoft. Recuperado el 06 de 04 de 2012, de
http://www.ambysoft.com/essays/flootSpanish.html

55

3.3.5. Implementacin
Una vez concluidas las etapas de desarrollo de un sistema de informacin
(anlisis, diseo, implementacin y pruebas), llega el momento de poner el
sistema en funcionamiento, su instalacin o despliegue.
Antes de la instalacin propiamente dicha, es necesario planificar el entorno en el
que el sistema debe funcionar, tanto a nivel de hardware como a nivel de
software: equipos necesarios y su configuracin fsica, redes de comunicacin
entre los equipos y de acceso a sistemas externos de ser necesario, sistemas
operativos (actualizados para evitar problemas de seguridad), bibliotecas y
componentes suministrados por terceros, etc.
Objetivo: Disponer del sistema productivo en un ambiente de
produccin, metodologa de trabajo y manuales operativos. Se incluye,
de ser necesario, el personal operativo capacitado. Obtencin de
nuevas funciones a agregar o posibles errores a reparar.
Tareas: Puesta en marcha de la aplicacin en el ambiente de
produccin, elaboracin de manuales operativos, y todas las
actividades relacionadas al xito del lanzamiento como la integracin
del ambiente de produccin con terceras partes, etc.
Entregables: El sistema productivo con sus manuales operativos, de
mantenimiento y de procedimientos. Sistema totalmente probado.

56

3.4. Herramientas
3.4.1. Tcnicas de relevamiento
Para la ejecucin del presente proyecto se utilizar la observacin, las
entrevistas con el cliente y los usuarios como principal tcnica de relevamiento.
3.4.2. Casos de Uso
Son un mtodo prctico para explorar requerimientos. Ayudan a describir
qu es lo que el sistema debe hacer desde el punto de vista del usuario. Por lo
tanto, se considera que los casos de uso proporcionan un modo claro y preciso de
comunicacin con el cliente. Los diagramas de casos de uso describen las
relaciones y las dependencias entre un grupo de casos de uso y los actores
participantes en el proceso.
Es importante resaltar que los diagramas de casos de uso no estn pensados
para representar el diseo y no puede describir los elementos internos de un
sistema. Los diagramas de casos de uso sirven para facilitar la comunicacin con
los futuros usuarios del sistema, y con el cliente, y resultan especialmente tiles
para determinar las caractersticas necesarias que tendr el sistema. Esto es, los
diagramas de casos de uso describen qu es lo que debe hacer el sistema, pero
no cmo.
Una vez realizados los diagramas de casos de uso, que describen grficamente lo
que debe hacer el sistema, se detallan los casos de uso, en ellas se explica la
forma de interactuar entre el sistema y el usuario.
Los casos de uso son utilizados durante la etapa de anlisis.

57

Para la ejecucin del presente proyecto se utilizar el formato de especificacin
de requerimientos presentado en la Figura 16.

Figura 16.Plantilla para especificacin de casos de uso.
3.4.3. Diagrama de Entidad Relacin (DER)
Un modelo de datos describe de una forma abstracta cmo se representan
los datos, sea en una empresa, en un sistema de informacin o en un sistema de
base de datos.
Como herramienta para el modelado de datos de un sistema de informacin, los
DER expresan entidades relevantes y sus inter-relaciones. Formalmente, son un
lenguaje grfico para describir conceptos y describen la informacin utilizada en
un sistema de informacin.
El modelo de datos entidad-relacin est basado en una percepcin del mundo
real que consta de una coleccin de objetos bsicos, llamados entidades, y de
relaciones entre esos objetos.
Nombre
ID <Identificados del caso de uso en el diagrama>
Descripcin <Descripcin del caso de uso>
Precondicin <Concisiones que deben presentarse antes de llegar al
caso de uso>
Post condicin <Concisiones generadas por el caso de uso>
Flujo Normal <Descripcin del flujo normal del caso de uso>
Flujos Alternos <En caso de que el caso de uso puede tener flujos
alternos, describirlos en esta parte>
Excepciones <Las excepciones a los flujos normales tambin son
importantes>
Notas: <Otros datos que aporten a la implementacin.

58


Figura 17.Ejemplo Diagrama Entidad Relacin
3.4.4. Sprintometer
Permite llevar a cabo el seguimiento del proyecto. Es una herramienta de
automatizacin de procesos giles que admite a los equipos auto organizarse y
aumentar la productividad. Esta herramienta, de acceso libre y fcil de utilizar, es
una aplicacin de escritorio que permite alojar en la nube de forma gratuita los
datos referentes al proyecto y compartir la informacin del proyecto entre todo el
equipo.
Esta herramienta para la administracin del proyecto permite:
Manejar proyectos y definir para cada proyecto los Sprint, las historias de
usuario (Story) y las respectivas tareas asociadas a cada historia.
Actualizar continuamente los avances realizados en las tareas asignadas.
Observar un grfico por cada Sprint que indica la velocidad con la que
avanza el proyecto. Estos grficos llamados burndown no slo permiten

59

observar el estado de avance del proyecto, sino tambin analizar sus
comportamientos e ir aprendiendo para mejorar los Sprints que restan.
Esta herramienta ser utilizada en todas las etapas de cada Sprint.

Figura 18. Definiciones Sprintometer
3.4.5. Visual Studio 2010

Microsoft Visual Studio es un entorno de desarrollo integrado para sistemas
operativos Windows. Soporta varios lenguajes de programacin tales como Visual
C++, Visual C#, Visual J#, ASP.NET y Visual Basic .NET, aunque actualmente se
han desarrollado las extensiones necesarias para muchos otros lenguajes como
pyton, ruby, etc.
Visual Studio permite a los desarrolladores crear aplicaciones, sitios y
aplicaciones web, as como servicios web en cualquier entorno que soporte la
plataforma .NET (a partir de la versin .NET 2002). As se pueden crear

60

aplicaciones que se intercomuniquen entre estaciones de trabajo, pginas web y
dispositivos mviles.
Estas caractersticas han hecho que se elija Visual Studio 2010 como la
herramienta de desarrollo para codificar el presente proyecto.
Esta herramienta es utilizada durante la etapa de construccin.

Figura 19.Herramienta de desarrollo VS2010.
3.4.6. Jira
JIRA es una herramienta de gestin de proyectos en lnea que ayuda a los
equipos a construir mejor software gestionando principalmente bugs, tareas
permitiendo un continuo monitoreo de actividades, y obtener informes sobre el
estado de las incidencias o bugs levantada, especialmente en la etapa de
pruebas. De esta manera tanto el equipo de desarrollo como los dueos del
producto, pueden conocer el estado de los errores reportados.
Este tipo de herramientas son de gran utilidad cuando el equipo de trabajo no se
encuentra fsicamente juntos, lo cual no implica que deban permanecer
desinformado del estado del proyecto y en este caso particular de los errores
reportados.

61

CAPTULO 4
4.1. Ejecucin del Proyecto
4.1.1. Planificacin
Como se haba mencionado en el captulo anterior, la primera fase de del proceso
de desarrollo es la planificacin; esta tapa al igual que el resto de etapas sern
analizadas una vez durante el desarrollo de cada Sprint. Sin embargo, antes de
iniciar con las iteraciones, es necesario realizar una definicin macro de las
iteraciones, esto es, realizar una planificacin inicial, que permita identificar el
propsito de cada iteracin y definir en forma global lo que se realizar en cada
sprint. Este anlisis inicial se denomina Sprint 0.
Antes de definir el nmero y los objetivos de cada Sprint a desarrollar durante la
ejecucin del presente proyecto, es necesario definir ciertas actividades, una de
ellas, el anlisis preliminar de los procesos del negocio, definir los alcances del
presente proyecto, realizar una estimacin de tiempos y recursos a utilizar.
4.1.1.1. Anlisis de Procesos
En captulos anteriores del proyecto ya se haba definido el alcance
general, en este captulo, es necesario definir los alcances funcionales del
sistema informtico que se implementar como parte de la ejecucin del proyecto.
Para definir los alcances funcionales, se analizarn los procesos ya definidos
internamente por ASISTECOM.
Macro Proceso LECTOFACTURACION: Es el conjunto de procesos
operativos que ASISTECOM ofrece a sus clientes. Estos pueden ser:

62

Lectura de medidores de consumo IN SITU (Lecturas), entrega de facturas
de consumo (Reparto), lectura de consumo y facturacin IN SITU (lecto-
facturacin), entre otros.
Proceso Lectura de medidores de consumo IN SITU: Proceso
mediante el cual se recolecta informacin correspondiente al consumo
registrado en los medidores de los abonados al servicio brindado por los
clientes de ASISTECOM, principalmente empresas de servicios
pblicos (Empresa elctrica, Empresa de Agua Potable).

Figura 20.Proceso de Lectura de medidores de consumo IN SITU
Fuente: Editado de Manuales de procedimientos ASISTECOM

Los subprocesos de la Figura 20.Proceso de Lectura de medidores de consumo
IN SITU sern descompuestos un diagrama que permita analizarlos
detalladamente. Los procesos analizados son los siguientes:

63

Descarga/Cargar de Plan: subproceso mediante el cual se descarga
un archivo con los dados proporcionados por el cliente, con la lista de
suministros y datos necesarios para realizar las lecturas y se carga en
el sistema para su posterior asignacin.
Asignacin Rutas: subproceso mediante el cual, las lecturas son
divididas y asignadas a los Operadores lecturistas para realizar las
lecturas In Situ.
Sincronizacin de Lecturas:
o Pendientes: subproceso mediante el cual, las lecturas asignadas
a un operador lecturista, son sincronizadas a los dispositivos
mviles de su responsabilidad para ser gestionadas en campo.
o Gestionadas: subproceso mediante el cual, se actualizan los
datos de las lecturas gestionadas.
Registro de Lectura: subproceso en el cual los operadores lecturistas
toman el valor del consumo de las lecturas asignadas para su gestin y
la registran en los dispositivos mviles, para su posterior sincronizacin.
Control y verificacin: subproceso mediante al cual un operador del
sistema verifica la consistencia de la informacin recolectada por los
operadores lecturistas previo su retorno al cliente.

64

Supervisor de Operaciones Asist ente de Operaciones Operador Lecturista
FIN
PROCESO
<<NO>>
<<SI>>
<<NO>>
<<NO>>
<<SI>>
<<SI>>
<<SI>>
<<NO>>
<<NO>>
Ini cio
NO
NO
SI
SI
Plantillas Distributivo
<<NO>>
<<NO>>
<<NO>>
<<SI>>
<<SI>>
<<SI>>
<<SI>> <<SI>>
<<SI>>
<<NO>>
Descarga Archivo Cargar Plan
Solicitar Plantilla Distributivo
Archivo Lecturas Plan
DB Lecturas
Rura 1
Ruta 2
Rut a n
Seleccin Plan
Distributivo
Asignacin
Reportar Pl an Listo
Recepcin Distributivo
Distributivo Pl an(Actualizado)
Recepcin de equipos
Lect uras gestionadas? Lect uras Asignadas?
DB Asignadas/Gestionadas
Sincronizar Gestionadas
Si ncroniza Asi gnadas
Verificacin Si ncronizacin
Entrega PK Supervisor
Recepci n PK
Selecciona lectura
Tomar lectura
Guardar lectura
Desbloquear Lectura
Ingresa novedades
Ingresa lectura nuevament e
Lectura Bloqueada?
Tiene Novedad?
Debe Ratif icar?
Lectura Desbloqueada?
Lecturas Pendientes?
Lect ura Ratif icada?
Exede intentos?
Bloquear lect ura
EntregaPK
Valida Datos Recolect ados
Ti ene Lectura?
Dent ro Rango
Justifica NO Lectura
Ratifica Lectura?
Fecha y hora Correctos
Cdigos bien apli cados
Edita Lectura
Edita Lectura Ratifi cada
Edi ta Cdigos
Edi ta Fecha y Hora
Rendir Plan
Archivo Lecturas Plan Rendido
Subir Archivo
Actualizar Lectura
Figura 21 - Diagrama de procesos

65

Tabla 6.Simbologia utilizada en los diagramas
Nombre Smbolo Funcin
Terminal

Representa el inicio y fin de un
programa. Tambin puede
representar una parada o
interrupcin programada que
sea necesaria realizar en un
programa.
Proceso

Cualquier tipo de operacin que
pueda originar cambio de valor,
formato o posicin de la
informacin
Decisin

Indica operaciones lgicas o de
comparacin entre datos
Indicador de direccin
o lnea de flujo

Indica el sentido de la ejecucin
de las operaciones
Indicador de
dependencia

Indica que un proceso depende
de un recurso (Salida)
Salida

Recurso utilizado para la
ejecucin de un proceso o
generado durante la ejecucin
del proceso.
Datos Almacenados

Representa un conjunto de
datos, generalmente en Base de
datos.

Process_01
Fi l e_01
Resource_01

66

De los procesos descritos y el respectivo diagrama, de han identificado los
requisitos funcionales y no funcionales con los cuales debe cumplir el sistema a
implementar y se encuentran descritos en la Tabla 7.
Tabla 7. Requerimientos Funcionales/No Funcionales Sprint 0
Mdulo
a
Requisitos funcionales Requisitos no funcionales
1.1 El sistema brindar seguridad para ser utilizado por
usuarios registrados del sistema, con diferentes
niveles de acceso.
(Este tema no fue levantado por el dueo del
producto, pero es necesario)
1.2 El sistema permitir registrar a los usuarios del
sistema.
El sistema funcionar en equipos con S.O.
Windows con .Net Framework 3,5
1.3 El sistema permitir registrar los equipos
utilizados para el procesos de recoleccin de
datos en campo

1.4 El sistema permitir asignar al usuario
responsable de un equipo.

2.1 El sistema permitir cargar los datos de un plan a
la base de datos desde un archivo de texto
(Archivo plano separado por comas
[columna1],[columna2]).
Este proceso debe ser eficiente, debido a que
actualmente toma demasiado tiempo. Es necesario
implementar un mtodo rpido para cargar los
datos en la DB. Se probara el mtodo por build
copy
2.2 El sistema permitir consultar los datos del plan
cargado.

2.3 El sistema permitir consultar, seleccionar y
asignar y reasignar rutas a gestionar (bloque de
lecturas )a un usuario del sistema.

2.4 El sistema permitir sincronizar las lecturas
asignadas a un usuario, al equipo (pocket) para
su respectiva gestin en campo.

2.5 El sistema permitir sincronizar las lecturas
gestionadas por un usuario para actualizar los
datos requeridos en la base de datos.

3.1 El sistema permitir recolectar la informacin en
campo, utilizando una aplicacin instalada en los
pockets utilizados actualmente.
La aplicacin mvil funcionar el dispositivos
mviles con S.O Windows Mobile 6.0 o superior
con .Net Compact Framework 3,5

67

Mdulo
a
Requisitos funcionales Requisitos no funcionales
2.6 El sistema permitir sincronizar los datos de las
lecturas gestionadas y por gestionar utilizando la
interfaz USB.

4.1 El sistema permitir sincronizar los datos de las
lecturas gestionadas y por gestionar utilizando la
red de datos proporcionada por las operadoras de
telefona celular.
La sincronizacin de datos se realizar utilizando
un plan de datos de internet de los disponibles por
las operadoras de telefona celular, el proveedor no
debe ser un limitante.
2.7 El sistema permitir identificar quien gestiono las
lecturas, en cualquiera de las formas de
sincronizacin.

2.8 El sistema permitir modificar las lecturas
gestionadas en campo desde la aplicacin de
escritorio.

2.9 El sistema almacenara los datos de los planes
gestionados permanentemente.

5 El sistema permitir obtener los siguientes
reportes.

5.1 *Reportes de asignacin de lecturas (Distributivo
Plan Actualizado con nmero de lecturas por lecturista)

5.2 *Reportes de asignacin de lecturas (histrico del
anterior)

5.3 *Reportes de lecturas realizadas por cada
lecturista. (Detalle del Distributivo Plan Actualizado
con nmero de lecturas por lecturista)

5.4 *Reporte Plan Rendido
5.5 Estado de sincronizacin (Resumen del plan
rendido)

Nota: La lista de requerimientos ha sido socializada con los dueos del producto, los especialistas
del rea de Operaciones.
a
La columna identifica tentativamente el mdulo en el cual se incluirn las funcionalidad. Los
mdulos sern a su vez tentativamente el alcance propuesto para los Sprints. Los mdulos
identificados durante el anlisis son los siguientes:
1.-M. Administracin
2.-M. Gestin (Procesamiento de la informacin)
3.-M. Gestin en campo (Aplicacin para dispositivos mviles)
4.-M. Sincronizacin en lnea.
5.-M. Reportes



68

4.1.2. Alcance del software
De acuerdo al anlisis de los procesos y las funcionalidades identificadas, el
software a desarrollarse tendr los siguientes alcances.
Mdulo de administracin (1 en Tabla 7), que permitir:
o Crear, eliminar, modificar usuarios, equipos y perfiles para
controlar el acceso a los diferentes mdulos del sistema
Mdulo de Gestin (2 en Tabla 7), que permitir:
o Cargar y procesar la informacin proporcionada y requerida por el
cliente de ASISTECOM.
o Sincronizar desde y hacia los dispositivos mviles los datos de las
lecturas gestionadas y las asignadas para su gestin, utilizando la
interfaz USB de los dispositivos mviles.
o Consultar reportes de asignacin (5.1, 5.2 y 5.3 en Tabla 7.
Requerimientos Funcionales/No Funcionales), los cuales permitan
dar seguimiento del proceso.
o Reporte de planes Rendidos (5.4 en Tabla 7. Requerimientos
Funcionales/No Funcionales).
Mdulo de Gestin en campo (3 en Tabla 7), aplicacin para
dispositivos mviles, basados en Windows Mobile que permitir:
o Llevar a cabo el proceso de recoleccin y validacin de
informacin con dispositivos mviles.

69

Mdulo de Sincronizacin en lnea (4 en Tabla 7), que permitir:
o Utilizar la red de datos proporcionada por una operadora de
telefona celular local para:
Descargar los datos de las lecturas asignadas a un
Lecturista, para su respectiva gestin.
Actualizar los datos de las lecturas gestionas por el
Lecturista, en el servidor central de ASISTECOM.
o Consultar reportes de estado de sincronizacin (5.5 en Tabla 7.
Requerimientos Funcionales/No Funcionales), los cuales permitan
dar seguimiento del proceso.
4.1.3. Conformacin del equipo de trabajo
Al igual que en cualquier otro tipo de proyecto, es necesario conocer el equipo
humano con que se cuanta para trabajar en el proyecto.
El equipo de trabajo para llevar a cabo el Software para RECOLECCIN MASIVA
DE INFORMACIN CON TECNOLOGA MVIL estar conformado segn lo
descrito en la tabla 8.



ESPACIO EN BLANCO INTENCIONAL


70

Tabla 8. Equipo de Trabajo y Roles
ROL Persona rea
a

Product Owner Evelyn Herrera Gerencia I.T.- ASISTECOM
SCRUM Master Kleber Toapanta Desarrollo Outsourcing
Team

Kleber Toapanta Desarrollo Outsourcing
Evelyn Herrera Gerencia I.T.- ASISTECOM
Ral Izquierdo Gerencia Comunicaciones - ASISTECOM
Rubn Ortega Soporte Tcnico Operativo - ASISTECOM
Francisco Meza Jefe Regional Operativo - ASISTECOM
Nota: Klber Toapanta participa en ms de un rol, esto es completamente factible como parte de
la metodologa. Esta tabla es una reproduccin parcial del acta AS-AR-PRIEE-001-2011, en la
cual se estableci el equipo de trabajo. Durante la etapa de planificacin (Sprint0). Se conformar
el equipo as y se definirn los roles de cada miembro en la planificacin de cada Sprint del
proyecto.
a
Columna que identifica la rea de actual de trabajo del participante del proyecto.

4.1.4. Definicin del Backlog del Producto.
El Backlog Del Producto contiene toda la funcionalidad que el producto final
debera tener. Tal como lo dice la metodologa, para el presente proyecto se ha
elaborado el Backlog del producto, identificando las funcionalidades, priorizando
cada una de ellas y realizando una estimacin del tiempo requerido para su
implementacin.
De acuerdo al estudio de los procesos y los requerimientos identificados durante
la etapa de anlisis, el Backlog del Producto para el presente proyecto se
encuentra definido en la siguiente tabla:

71

Tabla 9. Backlog Producto
ID
Nombre Importancia
a
Tiempo
estimado
(semanas)
b

Comentarios
1
Mdulo de
Administracin 700 3
Funcionalidad para
administracin de recursos.
2 Mdulo de Gestin 800 3
Funcionalidad para gestionar
informacin (in-out) de los
clientes de ASISTECOM.
3
Mdulo de Gestin
en Campo 900 3
Aplicacin para dispositivos
mviles, con funcionalidad
para recoleccin y
almacenamiento de
informacin en campo con
dispositivos mviles.
4
Sincronizacin en
lnea 1000 3
OBJETIVO PRINCIPAL,
agilitar el proceso de
sincronizacin de datos.

Nota: Esta tabla una reproduccin parcial del acta AS-AR-PRIEE-002-2011, en la cual se
estableci lista priorizada de requisitos para el presente proyecto.


a
La importancia est estimada de acuerdo a las necesidades del Product Owner y esta
cuantificada con nmeros enteros entre 0 y 1000, de acuerdo a la escala de la Figura 22.

b
El tiempo requerido para el desarrollo est dado principalmente por dos factores: El tiempo
recomendado por SCRUM para la ejecucin de cada iteracin y la experiencia en la
implementacin de componentes de software del equipo de trabajo. En este caso cada mdulo
ser implementado en una iteracin independiente.

Figura 22.Escala Importancia Definida por Product Owner.


72

4.1.5. Diseo
4.1.5.1. Modelo de datos
En esta etapa de definir en forma general, el modelo de datos que sern
implementados en los siguientes Sprints. Este modelo ser la gua de referencia
para la implementacin detallada de cada mdulo.

Figura 23.Modelo de Datos del Sistema
4.1.5.2. Arquitectura General
Para la implementacin del sistema para RECOLECCIN MASIVA DE
INFORMACIN CON TECNOLOGA MVIL, se utilizar un modelo N Capas,
distribuidas de la siguiente manera:

73

Capa de Presentacin (GUI): presenta el sistema al usuario, muestra la
informacin existente y captura la informacin del usuario con un mnimo
de proceso.
Capa de negocio (BLL): donde residen los programas que se ejecutan, se
reciben las peticiones del usuario y se envan las respuestas tras el
proceso. Es aqu donde se establecen todas las reglas que deben
cumplirse. Esta capa se comunica con la capa de presentacin y con la
capa de datos, para solicitar al gestor de base de datos almacenar o
recuperar datos del sistema.
Es posible almacenar la lgica del negocio sobre cada estacin cliente, u
optar por ejecuta la lgica sobre un servidor de aplicaciones. En este caso,
debido al reducido nmero de estaciones cliente que ejecutaran esta
aplicacin (dos o tres estaciones cliente), es posible utilizar la primera
opcin. Cuando el nmero de clientes es considerable (superior a 10
estaciones cliente), es recomendable utilizar un servidor de aplicaciones
que concentre toda la lgica del negocio.
Capa de datos (DAL): es donde residen los datos y es la encargada de
acceder a los mismos. Est formada por uno o ms gestores de bases de
datos que reciben solicitudes de almacenamiento o recuperacin de
informacin desde la capa de negocio.
Capa Entidades del Negocio (BEL): Es la representacin de los objetos
manejados en el sistema y tambin de las tablas de la base de datos.
Permiten el transporte de los datos desde fuera hacia la base de datos y

74

viceversa. Maneja el principio de programacin con objetos los cuales
contienen atributos que representarn datos fsicos.

Figura 24. Arquitectura Aplicacin
4.1.6. Sprint1 Mdulo de Administracin
El primer sprint tiene como objetivo implementar las funcionalidades
requeridas para la administracin de recursos utilizados por el sistema, esto es;
Crear, eliminar, modificar usuarios, equipos y perfiles para controlar el acceso a
los diferentes mdulos del sistema.
4.1.6.1. Planificacin
Para la planificacin del Sprint1, se llev a cabo una reunin con el Product
Owner, segn consta en el acta AS-AR-PRIEE-003-2011. En esta reunin se
realiza un anlisis de los procesos y las funcionalidades que sern
implementados.

75

De la Tabla 7. Requerimientos Funcionales/No Funcionales Sprint 0, obtenida
durante el Sprint0, se selecciona las funcionalidades correspondientes al mdulo
que ser el objetivo del Sprint1.
Tabla 10.Requerimientos Funcionales/No Funcionales- Sprint1
REQUISITOS FUNCIONALES REQUISITOS NO FUNCIONALES
El sistema permitir registrar a los usuarios
del sistema.
El sistema brindar seguridad para ser utilizado por
usuarios registrados del sistema, con diferentes
niveles de acceso.
Los usuarios no deben ser eliminados del
sistema para mantener consistencia en la
informacin histrica.
El sistema funcionar en equipos con S.O.
Windows con .Net Framework 3,5

El sistema permitir registrar los equipos
utilizados para el procesos de recoleccin de
datos en campo
El sistema permitir asignar equipos
registrados a usuarios registrados del
sistema.
Un usuario puede tener ms de un equipo
asignado y un equipo solo puede estar
asignado a un usuario.
El sistema debe manejar niveles de
seguridad para diferentes grupos de
usuarios.



76

De acuerdo a las funcionalidades identificadas para el mdulo de administracin,
se identifican las historias de usuario para el Sprint1.
Tabla 11.Historias de Usuario - Sprint 1
ID
Historia de
usuario
Importancia
Product
Owner
a

Importancia
Tcnica
b

Descripcin
1 Creacin de
perfiles
500 1000 Es necesario manejar niveles de acceso para los
usuarios, y para ellos es importante manejar usuarios
agrupados en perfiles.
2 Iniciar
sesin en el
sistema
500 1000 Consiste en brindar seguridad al acceso de la
aplicacin, permitiendo que nicamente usuarios
autorizados puedan tener acceso al mismo.
3 Administraci
n de
usuarios
800 800 El sistema requiere de un nmero variable de usuarios
con diferentes funciones, por lo que es necesario
administrar los usuarios y agruparlos en perfiles con
diferentes niveles de acceso a la aplicacin.
4 Administraci
n de
Equipos
800 800 El sistema requiere la utilizacin de un nmero variable
de equipos mviles (pockets [PK]) que puedan ser
utilizados en el proceso de gestin de informacin en
campo. Por tanto la aplicacin debe registrar los
equipos que se utilizan
5 Asignacin
de equipos
1000 800 Para que se realice el trabajo de campo, los lecturistas
utilizan equipos (PK); para ello cada usuario lecturista
deber tener asignado un PK de los registrados en el
sistema y con el que realizar la gestin de lecturas.
Nota: Esta tabla una reproduccin parcial del acta AS-AR-PRIEE-002-2011, en la cual se
estableci lista priorizada de requisitos para el Sprint1.

a
La importancia est estimada de acuerdo a las necesidades del Product Owner y est
cuantificada con nmeros enteros entre 0 y 1000, de acuerdo a la escala de la Figura 22.
b
La importancia tcnica est basada en las necesidades no funcionales desde el punto de vista
del usuario, pero necesarias para un funcionamiento de la aplicacin desde el punto de vista
tcnico.


77

Definicin del equipo de trabajo
El equipo de trabajo para la implementacin de las funcionalidades del mdulo de
administracin esta descrito en la siguiente tabla:
ROL Persona Descripcin/Tareas
Product Owner Evelyn
Herrera
Administracin del proyecto desde la perspectiva del
negocio.
SCRUM Master Kleber
Toapanta
Asegurar que el proceso SCRUM se lleve a cabo.
Team Codificacin Kleber
Toapanta
Codificacin de la las funcionalidades identificadas.

Pruebas Rubn Ortega Pruebas de las funcionalidades codificadas.

4.1.6.2. Anlisis
Una vez identificadas las historias de usuario, se identifican los actores y se
diagrama los casos de uso identificados para la implementacin del Sprint 1.
Actores del sistema
La siguiente tabla describe los actores que participan en los casos de uso
identificados para el mdulo de administracin.
Tabla 12.Actores del sistema
Actor Descripcin
Usuario
Administrador
Usuario con privilegios de administrador en el sistema. Este
tipo de usuario, puede gestionar todos los recursos
utilizados por el sistema



78

Diagramas de casos de uso del mdulo de administracin

Usuario Administrador
Administracin de Usuarios
Gestionar Usuarios
(RF-01)
Usuario Administrador
Administracin de Equipos
Gestionar Equipos
(RF-02)
extends
Asignar/Reasignar
Responsable (RF-03)
Usuario Administrador
Administracin de Perfiles
Seleccionar Perfil
(RF-10)
Seleccionar
Formulario (RF-5)
Seleccionar
Usuario (RF-04)
Definir Usuarios
del perfil (RF-08)
Definir Formularios
del perfil (RF-09)
uses
uses
uses
uses
Gestionar Pefiles
(RF-06)
Gestionar
Formularios (RF-07)
Seleccionar
Usuario (RF-04)
uses
Usuario Administrador
Administracin de Catlogos
Gestionar
Catlogos (RF-11)

Figura 25.Casos de uso - Administracin

79

Especificacin de casos de Uso
Los casos de uso de Figura 25 han sido especificados en las siguientes tablas:
Tabla 13.Especificacin del caso de uso: Gestionar Usuarios
ID RF-01
Descripcin Proporciona funcionalidades para dar mantenimiento a los usuarios del sistema.
Precondicin
Postcondicin Informacin actualizada de los usuarios del sistema.
Flujo Normal
1 El usuario logeado utiliza el formulario para mantenimiento de usuarios.
2 El sistema solicita los datos del nuevo usuario.
3 El sistema almacena los datos proporcionados.
Flujos
Alternos

* Usuario ya registrado
Si el usuario ya existe en el sistema y es necesario modificar la
informacin actual, el sistema proporciona la funcionalidad para
realizarlo.
Excepciones
1 Si se intenta registrar un usuario con Login, C.I. o Cd. ASISTECOM
que ya se encuentren registrados, el sistema debe advertir la situacin y
evitar que se registre el usuario.
Notas:
1 Se requiere los siguientes datos del usuario:
1.1. Login (*): Identificador nico de cada usuario con el cual se
autentificara en el sistema.
1.2. Clave de acceso (*): cdigo para acceso al sistema.
1.3. Nombres (*).
1.4. Apellidos (*).
1.5. Cdigo (*): Este cdigo es un identificador propio de la empresa y
los trabajadores de ASISTECOM cuentan con uno actualmente.
1.6 Identificacin
1.6.1 Tipo de identificacin
1.7. Direccin de domicilio.
1.8. Dos telfonos de contacto, adems de un numero celular (*).
1.9. Direccin de correo electrnico.

80

Tabla 14.Especificacin del caso de uso: Gestionar Equipos
ID RF-02
Descripcin Proporciona funcionalidades para dar mantenimiento a los equipos (PK)
utilizados para la recoleccin de informacin.
Precondicin
Postcondicin Informacin actualizada de los equipos mviles disponibles para la gestin de
lecturas.
Flujo Normal
1 El usuario logeado utiliza el formulario para mantenimiento de equipos.
2 Se ingresan los datos del nuevo equipo.
3 El sistema almacena los datos proporcionados.
Flujos Alternos
* El equipo ya est registrado
Si el equipo ya existe en el sistema y es necesario modificar la
informacin actual, el sistema proporciona la funcionalidad para
realizarlo.
Excepciones
1 Si se intenta registrar un equipo con Nmero de serie o Cd.
ASISTECOM que ya se encuentren registrados, el sistema debe advertir
la situacin y evitara que se registre el PK.
Notas:
1 Se requiere los siguientes datos:


1.1. Cdigo (*): Este cdigo es un identificador nico propio con los que
los equipos utilizados por ASISTECOM son actualmente identificados.
Este cdigo debe ser registrado en los equipos.
1.2. Marca (*): Se seleccionar de un catalogo de marcas.
1.3. Modelo
1.4. Nmero celular
1.5. IMEI: Se debe revisar si es posible obtener, en la Aplicacin
DEMO, no fue posible de utilizar en todos los modelos probados.
1.6. Imagen: Debe existir la posibilidad de almacenar un registro grfico
del equipo.
1.7 Nmero de serie.
1.8 Fecha de registro.
1.9 Chip servicio internet
Los campos macados con (*) son obligatorios.

81


Tabla 15.Especificacin del caso de uso: Seleccionar Usuario
ID RF-03
Descripcin La asignacin de equipos y lecturas requieren de la seleccin de un usuario
registrado en el sistema, por tanto se debe poder seleccionar un usuario
para utilizar en los procesos mencionados.
Precondicin
1 Usuarios registrados en el sistema.

Postcondicin
? Lecturas asignadas al usuario seleccionado.
? Equipo asignado al usuario seleccionado.
Flujo Normal
1 Consulta de todos los usuarios registrados en el sistema y permite filtrar
de acuerdo a los perfiles existentes.
2 Filtrar informacin.
3 Seleccionar el usuario para utilizar en la tarea requerida.




82

Tabla 16.Especificacin del caso de uso: Asignar/Reasignar Responsable
ID RF-04
Descripcin Proporciona funcionalidades para asignar al usuario responsable de un
equipo (PK).
Precondicin
1 Usuarios registrados en el sistema.
2 Equipos registrados en el sistema en estado activo.


Postcondicin Informacin actualizada de los usuarios responsables de los equipos (PK).
Flujo Normal
1 El usuario logeado selecciona un equipo de los registrados en el
sistema.
2 El equipo no tiene un usuario asignado.
3 Se selecciona un usuario del sistema.
4 El sistema registra la asignacin del equipo al usuario.
Flujos Alternos
* Reasignacin
1 El usuario logeado selecciona un equipo de los registrados en el
sistema y este tiene asignado un usuario.
2 Se selecciona otro usuario del sistema.
3 El sistema actualiza la asignacin del equipo al usuario.
* Liberacin
1 El usuario logeado selecciona un equipo de los registrados en el
sistema y este tiene asignado un usuario.
2 Se elimina la asignacin, dejando el equipo libre para asignar a otro
usuario.
3 Se guardar un log de los eventos (asignacin/reasignacin).
Notas:
1. Un equipo debe ser asignado nicamente a un usuario.
2. Un usuario puede tener asignado ms de un equipo.
3. Debe ser posible exportar a Excel una lista con los detalles de la
asignacin.
4. El proceso de asignacin debe ser lo ms fcil posible, debido a la
alta frecuencia con que los usuarios cambian de equipos.


83

Tabla 17.Especificacin del caso de uso: Seleccionar Perfil
ID RF-05
Descripcin Consiste en consultar y seleccionar un perfil determinado, para asignar
usuarios o asignar formularios.
Precondicin
1 Perfiles registrados en el sistema.

Postcondicin
1 Perfil seleccionado para ser utilizado en diferentes procesos.

Flujo Normal
1 Consulta de todos los perfiles registrados en el sistema.
2 Filtrar informacin.
3 Seleccionar el perfil para utilizar en la tarea requerida.


Tabla 18.Especificacin del caso de uso: Seleccionar Formulario
ID RF-06
Descripcin Consiste en consultar y seleccionar un formulario (s), para asignar a un
determinado perfil.
Precondicin
1 Formularios registrados en el sistema.
Postcondicin
? Formulario asignado al perfil.

Flujo Normal
1 Consulta de todos los formularios registrados en el sistema.
2 Filtrar informacin.
3 Seleccionar formularios a asignar a un perfil.





84

Tabla 19.Especificacin del caso de uso: Gestionar Perfiles
ID RF-07
Descripcin Proporciona funcionalidades crear, modificar perfiles de usuario, los cuales
proporcionarn diferentes niveles de acceso a la aplicacin.
Precondicin

Postcondicin Informacin actualizada de los perfiles disponibles en el sistema.
Flujo Normal
1 El usuario logeado ingresa los datos de un perfil.
2 El sistema guarda la informacin de nuevo perfil.


Flujos Alternos
* El perfil ya existe
1 El usuario logeado selecciona un perfil existente
2 Se modifica la informacin del perfil
3 El sistema actualiza la informacin del perfil modificado.
* Eliminar perfil
1 El usuario logeado selecciona un perfil existente
2 Se solicita la eliminacin del perfil.
3 El sistema elimina de la DB los datos del perfil seleccionado.



85

Tabla 20.Especificacin del caso de uso: Gestionar Formularios
ID RF-08
Descripcin Proporciona funcionalidades para registrar informacin de los formularios
(pantallas) existentes en el sistema. Estas son posteriormente asignadas a
los perfiles existentes, para brindar acceso a las pantallas requeridas en un
perfil.
Precondicin
1 Desarrollo de los componentes GUI, con formularios utilizados en el
sistema.
Postcondicin Informacin actualizada con los datos de los formularios (pantallas)
disponibles en el sistema.
Flujo Normal
1 El usuario selecciona un componente GUI (Ejem: RMI.GUI*.DLL)
2 El sistema muestra todos los formularios disponibles en el componente.
3 El usuario selecciona un formulario.
4 El usuario ingresa una descripcin que permita identificar la utilizad que
tiene el formulario dentro del sistema, el mdulo en el cual es utilizado y
el estado (Activo/Inactivo).
5 El sistema registra el nuevo formulario disponible en el sistema.

Flujos Alternos
* El formulario ya existe
1 El usuario logeado selecciona un formulario existente.
2 Se modifica la informacin del formulario.
3 El sistema actualiza la informacin del formulario modificado.
* Eliminar Formulario
1 El usuario logeado selecciona un formulario existente.
2 Se solicita la eliminacin del formulario.
3 El sistema elimina de la DB los datos del formulario seleccionado.



86

Tabla 21.Especificacin del caso de uso: Definir Usuarios del perfil
ID RF-09
Descripcin Proporciona funcionalidades para asignar usuarios a un determinado perfil.
Precondicin
1 Usuarios registrados en el sistema.
2 Perfiles registrados en el sistema.

Postcondicin Usuarios asignados a un perfil de seguridad.


Flujo Normal
1 El usuario logeado selecciona perfil.
2 El usuario selecciona los usuarios para asignarlos al perfil.
3 El sistema alacena la informacin de los usuarios asignados al perfil.

Flujos Alterno
* Los usuarios ya han sido asignados, se requiere removerlos.
1 El usuario logeado selecciona perfil.
2 El usuario selecciona los usuarios que no deben pertenecer al perfil
3 El sistema alacena la informacin de los usuarios asignados al perfil.



87

Tabla 22.Especificacin del caso de uso: Definir Formularios del perfil
ID RF-10
Descripcin Proporciona funcionalidades para asignar formularios a un determinado perfil.
Precondicin
1 Usuarios registrados en el sistema.
2 Formularios registrados en el sistema.
Postcondicin Formularios asignados a un perfil de seguridad.
Flujo Normal
1 El usuario logeado selecciona perfil.
2 El usuario consulta los formularios existentes.
3 El usuario selecciona los formularios.
4 El sistema guarda la informacin de los formularios asignados al perfil.
Flujos Alternos
* Los formularios ya han sido asignados, se requiere removerlos.
1 El usuario logeado selecciona perfil.
2 El usuario consulta los formularios asignados al perfil.
3 El usuario selecciona los formularios que deben ser removidos del perfil
4 El sistema guarda la informacin de los formularios asignados al perfil.




88

Tabla 23.Especificacin del caso de uso: Gestin de Catlogos
ID RF-11
Descripcin Proporciona funcionalidades para crear, modificar catlogos utilizados en el
sistema. Esto permite agregar o eliminar dinmicamente listas de valores
utilizados como catlogos.
Precondicin

Postcondicin
1 Catlogos Actualizados
2 Detalles de catlogos actualizados.
Flujo Normal
1 Ingresar los datos del catlogo (Descripcin de las listas de valores).
2 El sistema guarda los datos del catlogo.
3 Ingresar detalles del catlogo (Los detalles corresponden a la lista de
valores del catlogo).
4 El sistema almacena la lista de detalles del catlogo.
Flujos Alternos
* El catlogo ya existe
1 El usuario logeado selecciona un catlogo existente.
2 Se modifica la informacin del catlogo y el sistema almacena la
informacin modificada (opcional)
3 Se actualiza la informacin de los detalles del catlogo. La
actualizacin puede incluir la adicin, eliminacin o actualizacin de los
detalles (Opcional).

4.1.6.3. Diseo
Modelo de datos
Del anlisis de la especificacin de los casos de uso, se determina la necesidad
de utilizar el modelo de datos descrito en el diagrama de entidad relacin de la
Figura 26.Diagrama Entidad Relacin-Mdulo Administracin, las mismas que
sern implementadas como objetos en la base de datos y como entidades del
negocio en la codificacin de la aplicacin.

89


Figura 26.Diagrama Entidad Relacin-Mdulo Administracin
4.1.6.4. Arquitectura
De la arquitectura planteada inicialmente para la aplicacin completa (Figura 24.
Arquitectura Aplicacin), la codificacin parta el mdulo de administracin se
implementar de la siguiente manera:
GUI: Formularios (pantallas) para:
Formularios para administracin de recursos
o Administracin de Usuarios
o Administracin de Equipos
o Administracin de perfiles

90

o Asignacin de usuarios al perfil
o Asignacin de formularios al perfil
Formularios comunes
o Principal
o Login
o Mensajes
Formulario para configuracin
o Configurar conexin a DB
BLL: Componentes para controlar la lgica de:
Administracin de recursos
o Administracin de Usuarios
o Administracin de Equipos
o Administracin de perfiles
o Asignacin de usuarios al perfil
o Asignacin de formularios al perfil
Lgica comn
o Seguridad
o Login
DAL: Componente para acceso a la capa de datos (DB)
BEL: Componente para administrar las entidades utilizadas en el sistema




91


Figura 27.Arquitectura Aplicacin de escritorio Mdulo de Administracin
Los siguientes diagramas describirn de manera detalladla como se
implementarn los requerimientos del mdulo de administracin.

Figura 28. Componentes - Mdulo Administracin
4.1.6.5. Construccin y Pruebas
Backlog del Sprint
Una vez identificadas las historias de usuario, las cuales se encuentran descritas
en los casos de uso y sus respectivas especificaciones, estas sern
implementadas en el primer sprint; para ello es necesario definir el Backlog del
sprint (pila de tareas) que permitan implementar las funcionalidades especificadas

92

en etapa de anlisis, aplicando diseo planteado. La pila de tareas para el Sprint1
se muestra en la siguiente tabla:
Tabla 24. Backlog Sprint Mdulo de Administracin
Story ID Task# Story Name, Task Name Assigned 1
Estimado
(Horas)
1 Iniciar sesin en el sistema
1 Componentes para Inicio de sesin Kleber Toapanta 8
2 Componentes para conexin DB Kleber Toapanta 8
3 Configuracin de conexin a DB Kleber Toapanta 6
4 Componentes base de la aplicacin Kleber Toapanta 8
5 Pruebas de desarrollo Kleber Toapanta 2

6 Pruebas unitarias Rubn Ortega 1
2 Administracin de usuarios
1 Componentes comunes Kleber Toapanta 8
2 Creacin Objetos DB Kleber Toapanta 5
3 Desarrollo GUI Kleber Toapanta 8
4 Pruebas de desarrollo Kleber Toapanta 2
5 Pruebas unitarias Rubn Ortega 1
3 Administracin de Equipos
1 Creacin Objetos DB Kleber Toapanta 5

2 Desarrollo GUI Kleber Toapanta 5
3 Pruebas de desarrollo Kleber Toapanta 2
4 Pruebas unitarias Rubn Ortega 1
4 Asignacin de equipos
1 Creacin Objetos DB Kleber Toapanta 3
2 Desarrollo GUI Kleber Toapanta 3
3 Pruebas de desarrollo Kleber Toapanta 1

4 Pruebas unitarias Rubn Ortega 1
5 Creacin de perfiles

1 Creacin Objetos DB Kleber Toapanta 4
2 Desarrollo GUI Kleber Toapanta 5
3 Pruebas de desarrollo Kleber Toapanta 2
4 Pruebas unitarias Rubn Ortega 1

Nota: Esta tabla una reproduccin parcial del reporte exportado desde la herramienta Sprint to
meter utilizada para gestionar el presente proyecto.


93


Para llevar un control integral de los avances de las tareas planteadas para
implementar las historias de usuario definida en la planificacin del sprint, las
tareas son subidas a la herramienta definida. En este caso Sprint to meter.

Figura 29. Backlog Sprint 1- Sprint to Meter
Fuente: Captura pantalla herramienta Sprint to Meter

Pruebas
Como se haba expuesto en el CAPTULO 1, seccin de Construccin y Pruebas,
las pruebas a realizar dependern del mdulo y componentes de los mismos. Los
resultados de las pruebas sern adjuntados como anexos al presente documento.
En ese contexto, los mtodos de pruebas utilizados en este mdulo son:
GUI: Formularios (pantallas) para:
Formularios para administracin de recursos -> Pruebas de Aceptacin

94

Formularios comunes -> Pruebas de Aceptacin
Formulario para configuracin -> Pruebas de Aceptacin


BLL: Componentes para controlar la lgica de:
Administracin de recursos -> Pruebas de unidad (Caja
Blanca)
Lgica comn -> Pruebas de unidad (Caja
Blanca)
DAL: Componente para acceso a la capa de datos (DB) -> Pruebas de unidad
(Caja Blanca, Caminos)
BEL: Componente para administrar las entidades. -> Pruebas de unidad
Para agilitar la etapa de pruebas, la persona asignada del equipo, utilizar la
herramienta JIRA, con esta gestionara y dar seguimiento a los errores
presentados durante la etapa de codificacin.

Figura 30.Reporte de errores JIRA
Fuente: Captura pantalla herramienta JIRA

95

4.1.7. Sprint2 Mdulo de Gestin
El segundo sprint tiene como objetivo implementar las funcionalidades
requeridas para la gestin planes de lectura, esto es; Cargar planes de trabajo en
el sistema, asignar/ reasignar lecturas a usuarios para su posterior gestin,
sincronizacin de datos (gestionados y pendientes) y actualizacin de lecturas
con los datos recolectados durante la gestin IN SITU.
4.1.7.1. Planificacin
De la Tabla 7. Requerimientos Funcionales/No Funcionales Sprint 0,
obtenida durante el Sprint0, se selecciona las funcionalidades correspondientes al
mdulo de gestin que sern implementadas en este Sprint.
Tabla 25.Requerimientos Funcionales/No Funcionales- Sprint 2
REQUISITOS FUNCIONALES REQUISITOS NO FUNCIONALES
El sistema permitir cargar los datos de un plan a
la base de datos desde un archivo de texto
(Archivo plano separado por comas
[columna1],[columna2]).
Este proceso debe ser eficiente, debido a que
actualmente toma demasiado tiempo. Es necesario
implementar un mtodo rpido para cargar los datos en
la DB. Se probara el mtodo por build copy
El sistema permitir consultar los datos del plan
cargado.


El sistema permitir consultar, seleccionar y
asignar y reasignar rutas a gestionar (bloque de
lecturas )a un usuario del sistema.
El sistema permitir sincronizar las lecturas
asignadas a un usuario, al equipo (pocket) para
su respectiva gestin en campo.
El sistema permitir sincronizar las lecturas
gestionadas por un usuario.

96

Una vez identificados los requerimientos funcionales y no funcionales se plantean
las historias de usuario que deben ser implementadas durante el desarrollo del
Sprint2.
Tabla 26.Historias de Usuarios Sprint 2
ID
Historia de
usuario
Importancia
Product
Owner
a

Importancia
Tcnica
b

Descripcin
1 Carga Plan
Trabajo
900 1000 Permite cargar los datos de las lecturas
proporcionadas por el cliente. Se buscara la
mejor alternativa para optimizar el proceso. (La
opcin propuesta es usar SQLXML)
2 Asignacin
Rutas-
Usuarios
800 800 Consiste en asignar lecturas de un plan de
trabajo a los usuarios lecturistas, para su
posterior gestin en campo.
3 Sincronizaci
n
800 800 Consiste en actualizar la informacin
recolectada en campo con los dispositivos
mviles y en enviar a los pocket la informacin
de las lecturas pendientes de gestin en
campo.
Nota:

a
La importancia est estimada de acuerdo a las necesidades del Product Owner y est
cuantificada con nmeros enteros entre 0 y 1000, de acuerdo a la escala de la Figura 22.
b
La importancia tcnica est basada en las necesidades no funcionales desde el punto de vista
del usuario, pero necesarias para un funcionamiento de la aplicacin desde el punto de vista
tcnico.