Académique Documents
Professionnel Documents
Culture Documents
POR:
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.
_________________________________
ING. MARCO VERGARA
DIRECTOR
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
ii
iii
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
iv
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
vi
NDICE DE CONTENIDO
CAPTULO 1 ...................................................................................................... 3
1.1.
Introduccin ....................................................................................... 3
1.2.
1.3.
Alcance .............................................................................................. 9
1.4.
Objetivos .......................................................................................... 11
CAPTULO 2 .................................................................................................... 13
2.1.
2.2.
2.2.1.
2.3.
2.3.2.
2.3.3.
2.4.
2.5.
SCRUM ............................................................................................... 28
2.5.1.
Introduccin .................................................................................. 28
2.5.2.
2.5.3.
CAPTULO 3 .................................................................................................... 42
3.1.
Metodologa......................................................................................... 42
3.2.
3.3.
3.3.1.
Planificacin.................................................................................. 45
3.3.2.
Anlisis ......................................................................................... 46
3.3.3.
Diseo .......................................................................................... 46
3.3.4.
vii
3.3.5.
3.4.
Implementacin ............................................................................ 55
Herramientas ....................................................................................... 56
3.4.1.
3.4.2.
3.4.3.
3.4.4.
Sprintometer ................................................................................. 58
3.4.5.
3.4.6.
Jira ................................................................................................ 60
CAPTULO 4 .................................................................................................... 61
4.1.
4.1.1.
Planificacin.................................................................................. 61
4.1.2.
4.1.3.
4.1.4.
4.1.5.
Diseo .......................................................................................... 72
4.1.6.
4.1.7.
4.1.8.
4.1.9.
4.2.
4.3.
viii
ix
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.
ABSTRACT
The current market is very competitive and always is changing.
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,
development methodologies.
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.
SCRUM
CAPTULO 1
1.1.
Introduccin
Existen en el medio muchas empresas para las cuales la recoleccin de
o de
puesto que esta puede transferirse desde y hacia algn sistema informtico que la
procese los datos.
DE INFORMACIN
http://apuntesyama.galeon.com/ischikawa.html
Existen equipos
ms eficientes, de
menor costo, pero
la empresa no
puede utilizarlos
Adquisicin de Nuevos
equipos
(2)
Frecuencia
Disminuir la necesidad de
soporte tcnico
(5)
Frecuencia
Disminuir la necesidad de
soporte tcnico
(6) Cambios
frecuentes
El proceso requiere
con frecuencia de
cambios en el
Sistema Informtico
Software propio,
facilidades para
mantenimiento en el
software
(7)
Tecnologa en
desuso
El actual proveedor
obliga a la
utilizacin de
tecnologa e
desuso
(8) Sin
soporte
tcnico
La tecnologa en
desuso, no tiene
soporte tcnico.
CUANTIFICACIN
CRITERIOS
PONDERACIN
1- 10
ACCIONES /
SOLUCIONES
(0) Nuevos
Equipos
Soporte
Tcnico
RESUMEN
Soporte
Tcnico
SUB CAUSAS
Utilizacin de nuevas
tecnologas
Mantenimiento
CAUSA
Existen nuevas
tecnologas, pero la
empresa no pude
hacer uso de estas
Subutilizados
(1) Nuevas
tecnologas
Plataforma
informtica
PESO
1
2
Software
Equipos
CRITERIOS
TOTAL
C
16
16
22
44
(4) Facilidad
(12)
Tiempos
de Uso
Control de trabajo
(software)
(10)
Costos por
(9) Imagen
Calidad de soporte
institucional
servicio
tcnico
3
4
Administracin
Personas
(3) Procesos
lentos
11 Excesivo
Existen procesos
que son demasiado
lentos con el
proveedor actual.
Se requiere
mantener mayor
control sobre el
trabajo del
personal.
Controlar de forma
eficiente el trabajo del
personal operativo
El software de
recoleccin de
datos debe ser de
fcil utilizacin para
el personal
operativo.
Gastos elevados
por mantenimiento
y soporte tcnico.
Se busca ampliar la
calidad del servicio Mejorar calidad de
que la empresa
servicio que se ofrece a
presta a sus
los clientes.
clientes
La calidad del
servicio influye en
la imagen de la
empresa.
14
42
26
104
1.2.2. Justificacin
1.3.
Alcance
10
Objetivos
Analizar el mtodo
proyecto.
11
propuesta
as
como
de
futuras
implementacin
de
Desarrollo, pruebas
12
CAPTULO 2
2.1.
Marco Terico
Este captulo tiene como objetivo, brindar una descripcin del marco terico
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.
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.
2.2.1.2.
MICROSOFT,
31
de
enero
es/library/ms195024%28v=vs.80%29.aspx>
de
16
2012
<http://msdn.microsoft.com/es-
Visin y Alcances.
Planificacin.
Desarrollo.
Estabilizacin.
Implantacin.
2.3.
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.
17
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 gil6, 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.
Los valores enumerados anteriormente inspiran los doce principios del manifiesto,
estos son:
I.
II.
19
III.
IV.
V.
VI.
VII.
VIII.
IX.
agilidad.
X.
La simplicidad es esencial.
XI.
XII.
20
SCRUM7
Figura 4. SCRUM
Fuente: Adaptado de (Epidata Consulting)
2.3.3.2.
ExtremeProgramming8
2.3.3.3.
Crystal Methodologies9
2.3.3.4.
Las tres ltimas son iterativas, adems de existir realimentacin a todas las
fases.
10
2.3.3.5.
2.3.3.6.
Lean Development(LD)12
pueden convertir en
FEATUREDRIVENDEVELOPMENT,31
de
2012<http://www.featuredrivendevelopment.com/>
12
POPPENDIECK,31 de enero de 2012 <http://www.poppendieck.com/>
25
enero
de
2.4.
26
Metodologas giles
Metodologas Tradicionales
preparados
cambios
de desarrollo.
para
durante
proyecto
Impuestas
internam ente
(por
el
Impuestas externamente
equipo)
Proceso menos controlado, con pocos Proceso mucho ms controlado, con numerosas
principios
polticas/normas
pequeos
mediante reuniones
(10
integrantes
Varios artefactos
Pocos roles
Varios roles
27
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.
28
Est basado en el hecho de que el trabajo es realizado por equipos autoorganizado y auto-dirigidos, logrando motivacin, responsabilidad y
compromiso.
29
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.
30
31
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
Implicados en el
proyecto
proyecto
-Marketing
-Equipo
-Comercial
-SCRUM Master
-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
32
33
Poda de requerimientos
Product Backlog
34
Sprint
35
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.
Requerimientos
de
recursos
de
infraestructura
logsticos
Dirigir la planificacin.
37
38
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:
40
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.
41
CAPTULO 3
3.1.
Metodologa
Se entiende por metodologa a la coleccin de documentacin formal
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.
Blanco,
S.
(s.f.).
Marble
Station.
Recuperado
http://www.marblestation.com/?p=644
42
el
15
de
03
de
2012,
de
3.2.
43
3.3.
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
44
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 .
45
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).
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?).
46
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.
especificaciones
49
de
los
documentos
de
alcance.
50
Figura 13.Modelo V 14
15
14
un
contexto
MDWE.
Recuperado
el
15
de
03
de
2012,
de
www.lsi.us.es/docs/doctorado/.../MemoInvestigArturoHTorres.pdf
15
contexto
MDWE.
Recuperado
el
15
de
www.lsi.us.es/docs/doctorado/.../MemoInvestigArturoHTorres.pdf
51
03
de
2012,
de
16
actualmente
implementados
en
los
procesos
operativos
de
16
(Ambler, 2004)
52
Tcnica
Descripcin
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
Prueba de Caja-Negra
interno.
Prueba de Valores-
Frontera
Prueba de Clases
Prueba de Integracin
de Clases
Revisin de Cdigo
el cdigo fuente.
Es el acto de validar que un componente funciona tal como est
una vez.
Una revisin tcnica en la cual se inspecciona un modelo de diseo.
Revisin de Diseo
Prueba de Regresin
de Herencia
Prueba de Integracin
Prueba de Mtodo
Revisin de Modelos
Prueba de Caminos
53
Tcnica
Descripcin
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
Revisin de Prototipos
Demostrar con el
cdigo
Prueba de Regresin
la aplicacin.
El acto de asegurar que el sistema funciona como se espera bajo
Prueba de Stress
Revisin Tcnica
Prueba de Escenarios
de Uso
Prueba de Interfaz de
Usuario
Prueba de Caja-Blanca
Nota: Las tcnicas utilizadas para probar el presente sistema dependern del mdulo y los
componentes a probar.
17
17
http://www.ambysoft.com/essays/flootSpanish.html
54
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.
elaboracin
de
manuales
operativos,
todas
las
55
3.4.
Herramientas
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.
Nombre
ID
Descripcin
Precondicin
Post condicin
Flujo Normal
Flujos Alternos
Excepciones
Notas:
57
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.
Manejar proyectos y definir para cada proyecto los Sprint, las historias de
usuario (Story) y las respectivas tareas asociadas a cada historia.
Observar un grfico por cada Sprint que indica la velocidad con la que
avanza el proyecto. Estos grficos llamados burndown no slo permiten
58
59
Estas caractersticas han hecho que se elija Visual Studio 2010 como la
herramienta de desarrollo para codificar el presente proyecto.
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.
60
CAPTULO 4
4.1.
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.
Anlisis de Procesos
SITU
sern
descompuestos
un
diagrama
que
62
permita
analizarlos
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
63
Descarga Archivo
Carga r Pla n
Ini cio
Recepci n PK
Entrega PK Supe rvisor
Se lecciona lectura
DB Le ctura s
NO
SI
<<SI>>
NO
SI
<<NO>>
Lectura Desbloq uea da?
<<SI>>
T oma r lectura
<<SI>>
Tie ne Nove dad ?
Re cepcin de e quip os
<<SI>>
<<NO>>
Guard ar le ctura
Re porta r Pl an L isto
<<SI>>
De be Ratificar?
<<SI>>
<<NO>>
Lectura Ratificad a?
<<NO>>
Distrib utivo
Lecturas Pen die ntes?
Rura 1
Ru ta 2
Ruta n
<<NO>>
Plan tilla s Distribu tivo
Justifica NO Le ctura
<<NO>>
Ti ene Lectura?
Dentro Rango
Ra tifica Le ctura?
<<NO>>
<<SI>>
<<SI>>
Edi ta Cdig os
<<SI>>
FIN
PROCESO
Sub ir Archivo
Re ndir Pla n
Archivo Le cturas Plan Rend ido
64
Nombre
Smbolo
Funcin
Representa el inicio y fin de un
programa.
Tambin
puede
representar
una
interrupcin
programada
parada
Terminal
que
Process_01
formato
posicin
de
la
informacin
Indica operaciones lgicas o de
Decisin
comparacin entre datos
Indicador de direccin
o lnea de flujo
de las operaciones
Indicador
de
dependencia
de un recurso (Salida)
Recurso
utilizado
para
la
ejecucin de un proceso o
Salida
generado durante la ejecucin
File_01
del proceso.
Representa
Datos Almacenados
Resource_01
conjunto
de
65
un
Mduloa
Requisitos funcionales
Requisitos no funcionales
El sistema brindar seguridad para ser utilizado por
1.1
sistema.
1.4
2.1
[columna1],[columna2]).
2.2
2.3
2.4
2.5
3.1
66
Mduloa
2.6
Requisitos funcionales
Requisitos no funcionales
4.1
red de datos proporcionada por las operadoras de las operadoras de telefona celular, el proveedor no
telefona celular.
2.7
2.8
2.9
5.1
5.2
5.3
5.4
5.5
Nota: La lista de requerimientos ha sido socializada con los dueos del producto, los especialistas
del rea de Operaciones.
a
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
67
en Tabla 7.
68
descrito en la tabla 8.
69
ROL
Persona
rea a
Gerencia I.T.- ASISTECOM
Ral Izquierdo
Rubn Ortega
Francisco Meza
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.
70
Nombre
Importanciaa
Tiempo
Comentarios
estimado
(semanas)b
ID
Mdulo de
1
Administracin
Funcionalidad para
700
administracin de recursos.
Funcionalidad para gestionar
informacin (in-out) de los
Mdulo de Gestin
800
clientes de ASISTECOM.
Aplicacin para dispositivos
mviles, con funcionalidad
para recoleccin y
almacenamiento de
Mdulo de Gestin
3
en Campo
dispositivos mviles.
OBJETIVO PRINCIPAL,
Sincronizacin en
4
lnea
agilitar el proceso de
1000
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.
71
4.1.5. Diseo
4.1.5.1.
Modelo de datos
4.1.5.2.
Arquitectura General
72
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
implementados.
74
REQUISITOS FUNCIONALES
REQUISITOS NO FUNCIONALES
del sistema.
informacin histrica.
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.
75
Historia de
ID
usuario
Creacin de
Importancia
Product
a
Owner
500
Importancia
Descripcin
Tcnicab
1000
perfiles
Iniciar
500
1000
sesin en el
aplicacin,
sistema
Administraci
n
800
800
de
permitiendo
que
nicamente
usuarios
usuarios
Administraci
n
800
800
de
Equipos
Asignacin
de equipos
1000
800
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.
76
ROL
Persona
Descripcin/Tareas
Product Owner
Evelyn
Herrera
negocio.
Kleber
SCRUM Master
Toapanta
Team
Codificacin
Kleber
Toapanta
Pruebas
4.1.6.2.
Rubn Ortega
Anlisis
Actor
Descripcin
Usuario
Administrador
77
Administracin de Usuarios
Gestionar Usuarios
(RF-01)
Usuario Administrador
Administracin de Equipos
Gestionar Equipos
(RF-02)
extends
Asignar/Reasignar
Responsable (RF-03)
uses
Usuario Administrador
Administracin de Perfiles
Gestionar Pefiles
(RF-06)
uses
Seleccionar
Usuario (RF-04)
Definir Usuarios
del perfil (RF-08)
uses
Seleccionar Perfil
(RF-10)
uses
Usuario Administrador
Definir Formularios
del perfil (RF-09)
uses
Seleccionar
Formulario (RF-5)
Gestionar
Formularios (RF-07)
Administracin de Catlogos
Gestionar
Catlogos (RF-11)
Usuario Administrador
78
Seleccionar
Usuario (RF-04)
RF-01
Descripcin
Precondicin
Postcondicin Informacin actualizada de los usuarios del sistema.
Flujo Normal
1
Usuario ya registrado
Flujos
Alternos
Notas:
1
RF-02
Descripcin
Precondicin
Postcondicin
Flujo Normal
1
Flujos Alternos
Notas:
1
la Aplicacin
80
RF-03
Descripcin
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.
81
RF-04
Descripcin
Precondicin
1 Usuarios registrados en el sistema.
2 Equipos registrados en el sistema en estado activo.
Postcondicin
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
Liberacin
82
RF-05
Descripcin
Precondicin
1
Filtrar informacin.
Postcondicin
Flujo Normal
RF-06
Descripcin
Precondicin
1 Formularios registrados en el sistema.
Postcondicin
?
Flujo Normal
1 Consulta de todos los formularios registrados en el sistema.
2 Filtrar informacin.
3 Seleccionar formularios a asignar a un perfil.
83
RF-07
Descripcin
Precondicin
Postcondicin
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.
84
RF-08
Descripcin
Precondicin
1 Desarrollo de los componentes GUI, con formularios utilizados en el
sistema.
Postcondicin
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.
85
RF-09
Descripcin
Precondicin
Postcondicin
Flujo Normal
1
Flujos Alterno
86
RF-10
Descripcin
Precondicin
Postcondicin
Flujo Normal
1
El usuario selecciona los formularios que deben ser removidos del perfil
Flujos Alternos
87
RF-11
Descripcin
Precondicin
Postcondicin
1 Catlogos Actualizados
El catlogo ya existe
Flujos Alternos
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
4.1.6.3.
Diseo
Modelo de datos
4.1.6.4.
Arquitectura
Formularios comunes
o Principal
o Login
o Mensajes
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
90
Los
siguientes
diagramas
describirn
de
manera
detalladla
como
se
4.1.6.5.
Construccin y Pruebas
Estimado
Story ID Task# Story Name, Task Name
1
Assigned 1
(Horas)
Kleber Toapanta
Kleber Toapanta
Configuracin de conexin a DB
Kleber Toapanta
Kleber Toapanta
Pruebas de desarrollo
Kleber Toapanta
Pruebas unitarias
Rubn Ortega
Administracin de usuarios
1
Componentes comunes
Kleber Toapanta
Creacin Objetos DB
Kleber Toapanta
Desarrollo GUI
Kleber Toapanta
Pruebas de desarrollo
Kleber Toapanta
Pruebas unitarias
Rubn Ortega
Administracin de Equipos
1
Creacin Objetos DB
Kleber Toapanta
Desarrollo GUI
Kleber Toapanta
Pruebas de desarrollo
Kleber Toapanta
Pruebas unitarias
Rubn Ortega
Asignacin de equipos
1
Creacin Objetos DB
Kleber Toapanta
Desarrollo GUI
Kleber Toapanta
Pruebas de desarrollo
Kleber Toapanta
Pruebas unitarias
Rubn Ortega
Creacin de perfiles
1
Creacin Objetos DB
Kleber Toapanta
Desarrollo GUI
Kleber Toapanta
Pruebas de desarrollo
Kleber Toapanta
Pruebas unitarias
Rubn Ortega
Nota: Esta tabla una reproduccin parcial del reporte exportado desde la herramienta Sprint to
meter utilizada para gestionar el presente proyecto.
92
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.
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.
Formularios comunes
Administracin de recursos
Blanca)
Lgica comn
Blanca)
DAL: Componente para acceso a la capa de datos (DB)
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
REQUISITOS FUNCIONALES
REQUISITOS NO FUNCIONALES
[columna1],[columna2]).
95
usuario
Carga Plan
Importancia
Product
Ownera
900
Descripcin
Tcnicab
1000
Trabajo
Asignacin
800
800
Rutas-
Usuarios
Sincronizaci
n
800
800
Consiste
en
actualizar
la
informacin
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.
96