downloading - Universidad Andres Bello

UNIVERSIDAD ANDRES BELLO
FACULTAD DE INGENIERÍA
INGENIERÍA EN COMPUTACIÓN E
INFORMÁTICA
“Faceschool”
Daniel Labra
Fernando Figueroa
PROYECTO DE TÍTULO PARA OPTAR AL
TÍTULO DE INGENIERO EN COMPUTACIÓN E
INFORMÁTICA.
Viña del Mar - Chile
Diciembre del 2014
1
Índice de Contenido
2.6
Índice de Tablas .................................................................................................................. 5
2.7
Índice de Figuras ................................................................................................................ 6
2.8
Resumen ............................................................................................................................... 8
Capítulo I........................................................................................................................................... 9
2.9
Introducción......................................................................................................................... 9
2.9.1 ¿Por qué es una necesidad? .......................................................................................... 9
2.9.2 Situación Actual ................................................................................................................ 10
Capitulo II ....................................................................................................................................... 12
2.10 Fundamentación del Tema ............................................................................................ 12
2.10.1 Problema............................................................................................................................. 12
2.10.2 Objetivos............................................................................................................................. 14
2.10.3 Objetivo General............................................................................................................... 14
2.10.4 Objetivos Específicos ..................................................................................................... 14
2.10.5 Alcance ............................................................................................................................... 14
2.10.6 Alcance del Proyecto ...................................................................................................... 14
2.10.7 Supuestos .......................................................................................................................... 15
2.10.8 Restricciones .................................................................................................................... 15
2.10.9 Modelo Canvas ................................................................................................................. 16
2.10.10 Mercado existente ......................................................................................................... 17
2.10.11 Alternativas de Solución .............................................................................................. 19
2.10.12 Solución Propuesta ....................................................................................................... 19
2.10.13 Esquema de solución ................................................................................................... 20
2.10.13 Factibilidad ...................................................................................................................... 21
2.10.14 Factores de Éxito ........................................................................................................... 23
2.10.15 Situación Futura ............................................................................................................. 24
2.10.16 Faceschool: Alto Nivel.................................................................................................. 26
Capítulo III ...................................................................................................................................... 38
2.11 Materiales y Métodos.......................................................................................................... 38
2.11.1 Fundamentación de la Metodología ............................................................................ 38
2.11.2 Metodología de Desarrollo ............................................................................................ 40
2.11.4 Organigrama y Roles ...................................................................................................... 44
2.11.5 Historias de Usuario ........................................................................................................ 51
2.12.6 Plan de Proyecto .............................................................................................................. 60
2.11.7 Product Backlog ............................................................................................................... 63
2.11.8 Gestión de Requerimientos........................................................................................... 68
2.11.9 Gestión de Riesgos ......................................................................................................... 68
2.11.10 Gestión de Configuración............................................................................................ 71
2.11.11 Control de versiones..................................................................................................... 71
2
2.11.12 Control de cambios ....................................................................................................... 76
2.11.13 Ambiente de Desarrollo................................................................................................ 78
2.11.14 Ambiente de Pruebas.................................................................................................... 79
2.11.15 Ambiente de Producción ............................................................................................. 80
2.11.16 Plan de Pruebas ............................................................................................................. 80
Capítulo IV ...................................................................................................................................... 84
2.12 Resultado y Discusión ....................................................................................................... 84
2.12.1 Sprint Nº1 ........................................................................................................................... 84
2.12.2 Planning Meeting.............................................................................................................. 84
2.12.3 Sprint Backlog .................................................................................................................. 85
2.12.4 EDT....................................................................................................................................... 86
2.12.5 Criterio de Aceptación .................................................................................................... 87
2.12.6 Sprint Backlog Tareas .................................................................................................... 90
2.12.7 Diseño Sprint Nº1 ............................................................................................................. 91
2.12.8 Evidencia Interfaces ........................................................................................................ 98
2.12.9 Pruebas Unitarias........................................................................................................... 101
2.12.10 Evidencia de seguimiento y control de cambios ................................................ 105
2.12.11 Liberación del Producto ............................................................................................. 106
2.12.12 Evidencia Línea base .................................................................................................. 106
2.12.13 Burndown....................................................................................................................... 107
2.12.14 Evolución de los Riesgos .......................................................................................... 108
2.12.15 Post Mortem Sprint Nº1 .............................................................................................. 109
2.12.13 Sprint Nº2 ....................................................................................................................... 110
2.12.14 Planning Metting .......................................................................................................... 110
2.12.15 Sprint Backlog .............................................................................................................. 111
2.12.16 Criterio de Aceptación ................................................................................................ 112
2.12.17 Sprint Backlog Táreas ................................................................................................ 114
2.12.18 Diseño Sprint Nº2 ......................................................................................................... 115
2.12.19 Evidencia Interfaces .................................................................................................... 121
2.12.20 Pruebas Unitarias ........................................................................................................ 123
2.12.21 Liberación del Producto ............................................................................................. 127
2.12.22 Evidencia Línea base .................................................................................................. 127
2.12.23 Burndown....................................................................................................................... 128
2.12.24 Evolución de los Riesgos .......................................................................................... 129
2.12.25 Post Mortem .................................................................................................................. 130
2.12.26 Sprint Nº3 ....................................................................................................................... 131
2.12.27 Sprint Planning Meeting............................................................................................. 131
2.12.28 Sprint Backlog .............................................................................................................. 132
2.12.29 Criterio de Aceptación ................................................................................................ 133
2.12.30 Sprint Backlog Tareas ................................................................................................ 134
2.12.31 Diseño Sprint Nº3 ......................................................................................................... 135
2.12.32 Evidencia Interfaces .................................................................................................... 140
2.12.31 Pruebas Unitarias ........................................................................................................ 142
2.12.32 Pruebas Ejecutadas .................................................................................................... 143
3
2.12.33 Liberación del Producto ............................................................................................. 147
2.12.34 Evidencia Línea base .................................................................................................. 148
2.12.35 Burndown....................................................................................................................... 149
2.12.36 Evolución de los Riesgos ......................................................................................... 149
2.12.37 Post Mortem .................................................................................................................. 151
Capítulo V ..................................................................................................................................... 152
2.13 Conclusiones ...................................................................................................................... 152
2.13.1 Trabajo futuro ................................................................................................................. 152
5.13.2 Conclusiones .................................................................................................................. 152
Anexo Plan de Pruebas ............................................................................................................ 153
Anexo Encuesta Nº1 .................................................................................................................. 165
4
2.6
Índice de Tablas
Tabla 1:Lean Canvas ..................................................................................................................... 16
Tabla 2: Requerimientos No Funcionales .................................................................................. 25
Tabla 3: Rol/Responsable ............................................................................................................. 46
Tabla 4: Funciones PO .................................................................................................................. 47
Tabla 5: Funciones Scrum Master ............................................................................................... 47
Tabla 6: Funciones Equipo Desarrollador .................................................................................. 47
Tabla 7:Rol-Integrante ................................................................................................................... 48
Tabla 8: Funciones Desarrollador ................................................................................................ 48
Tabla 9: Funciones Tracker .......................................................................................................... 49
Tabla 10: Funciones Coach .......................................................................................................... 49
Tabla 11: Funciones Consultor .................................................................................................... 50
Tabla 12: Funciones Big Boss ...................................................................................................... 50
Tabla 13:Gestión Riesgos ............................................................................................................. 70
Tabla 14: Control de Versiones .................................................................................................... 72
Tabla 15: Plan de Pruebas ........................................................................................................... 81
Tabla 16: Pruebas de Integridad BD ........................................................................................... 82
Tabla 17: Pruebas de Sistema ..................................................................................................... 82
Tabla 18: Pruebas de Rendimiento ............................................................................................. 82
Tabla 19: Pruebas de Interfaz ...................................................................................................... 83
Tabla 20: Pruebas de Carga......................................................................................................... 83
Tabla 21: Prueba Aceptación Ruta .............................................................................................. 88
Tabla 22: Prueba Aceptación Información.................................................................................. 89
Tabla 23: CRC Ruta Sprint Nº1 .................................................................................................... 91
Tabla 24: CRC Información Sprint Nº1 ....................................................................................... 92
Tabla 25: Criterio de Aceptación Búsqueda ............................................................................. 112
Tabla 26: Criterio de Aceptación Login ..................................................................................... 113
Tabla 27: CRC Login ................................................................................................................... 115
Tabla 28: CRC Búsqueda ........................................................................................................... 115
Tabla 29: Diseño de Prueba Búsqueda .................................................................................... 124
Tabla 30: Diseño de Prueba Login ............................................................................................ 125
Tabla 31: Sprint Backlog Sprint Nº3 .......................................................................................... 132
Tabla 32: Criterio Aceptación Sprint Nº3 .................................................................................. 133
Tabla 33: CRC Recomendador .................................................................................................. 135
Tabla 34: Pruebas Unitarias Recomendador Sprint Nº3 ........................................................ 142
Tabla 35: Evolución de los Riesgos Sprint Nº3 ....................................................................... 150
5
2.7
Índice de Figuras
Figura 1: Causa - Efecto ............................................................................................................... 13
Figura 2: Competencias ................................................................................................................ 18
Figura 3: Esquema Solución ......................................................................................................... 20
Figura 4 : Diagrama de Componentes ........................................................................................ 27
Figura 5: Diagrama de Despliegue .............................................................................................. 28
Figura 6: Diagrama de Secuencia Ruta ...................................................................................... 29
Figura 7: Diagrama de Secuencia Búsqueda por Criterio ....................................................... 30
Figura 8: Diagrama de Secuencia Información ......................................................................... 31
Figura 9: Diagrama de Secuencia Comparador ........................................................................ 32
Figura 10: Diagrama de Secuencia Administrar Colegio ......................................................... 34
Figura 11: Diagrama de Clases.................................................................................................... 37
Figura 12: Fases de Programación Extrema ............................................................................. 40
Figura 13 : Concepto Scrum ......................................................................................................... 42
Figura 14: Organigrama Scrum XP ............................................................................................. 50
Figura 15:Product Backlog ............................................................................................................ 66
Figura 16: Sprint Backlog .............................................................................................................. 85
Figura 17: EDT ................................................................................................................................ 86
Figura 18:Sprint Backlog Tareas.................................................................................................. 90
Figura 19: Diagrama Secuencia Ruta .......................................................................................... 93
Figura 20: Diagrama Secuencia Información ............................................................................. 94
Figura 21: Diagrama de Despliegue Sprint Nº1......................................................................... 95
Figura 22: Diagrama de Componentes Sprint Nº1 .................................................................... 96
Figura 23: Diseño de BD Sprint Nº1 ............................................................................................ 97
Figura 24: Prueba Unitaria Ruta ................................................................................................ 102
Figura 25: Pruebas Unitarias Información ................................................................................ 103
Figura 26: TRAC Pruebas ........................................................................................................... 104
Figura 27: TRAC ........................................................................................................................... 105
Figura 28: SVN ............................................................................................................................. 106
Figura 29: Sprint Backlog Nº2 .................................................................................................... 111
Figura 30: Sprint Backlog Tareas .............................................................................................. 114
Figura 31: Diagrama Secuencia Sprint Nº2 ............................................................................. 116
Figura 32: Diagrama Secuencia Sprint Nº2 ............................................................................. 117
Figura 33: Diagrama Despliegue Sprint Nº2 ............................................................................ 118
Figura 34: Diagrama Componentes Sprint Nº2 ....................................................................... 119
Figura 35: Diagrama de Clases Sprint Nº2 .............................................................................. 120
Figura 36: TRAC Pruebas ........................................................................................................... 126
Figura 37: SVN ............................................................................................................................. 127
Figura 38: Riesgos Sprint Nº2 .................................................................................................... 129
Figura 39: Sprint Backlog Tareas Sprint Nº3 ........................................................................... 134
Figura 40: Diagrama Secuencia Sprint Nº3 ............................................................................. 136
Figura 41: Diagrama de Despliegue Sprint Nº3....................................................................... 137
Figura 42: Diagrama de Componentes Sprint Nº3 .................................................................. 138
6
Figura 43: Diagrama de Clases Sprint Nº3 .............................................................................. 139
Figura 44: TRAC Pruebas ........................................................................................................... 146
7
2.8
Resumen
Actualmente existe un alto porcentaje de arrepentimiento de padres que
matriculan a sus hijos en un colegio inadecuado, que se ve afectado por múltiple
razones como lo son la escases de información, la preocupante cifra de colegios
que no poseen página Web etc. Sin lugar a dudas es un problema preocupante
que gracias al proyecto denominado Faceschool se pretenderá reducir,
promoviendo un sistema recomendador de colegios bajo las necesidades de cada
usuario, además se lograra concentrar una importante suma de colegios para que
así el usuario pueda tomar una decisión informado. Para desarrollar este proyecto
se ocuparan las metodologías
llamadas Scrum y Extreme Programming las
cuales nos proporcionan herramientas confiables para desarrollar un proyecto de
calidad.
Hoy en día el proyecto se ha desarrollado con buenos resultados, debido a
que se han podido implementar la mayoría de las funcionalidades que se tenía
previsto construir dentro de la planificación de la primera parte de nuestro
proyecto.
Dentro de las funcionalidades previstas en la planificación, están:
-
Geolocalización
-
Recomendador de colegios
-
La ruta más cercana hacia el colegio
-
Filtros según criterios de búsquedas, entre otras.
Podemos concluir que se ha satisfecho las los principales problemas que pudimos
indagar al principio de este proyecto, dándonos por satisfecho dentro de la
realización de este proyecto.
8
Capítulo I
2.9
Introducción
2.9.1 ¿Por qué es una necesidad?
La necesidad surge debido a que actualmente el proceso de realizar una
búsqueda por parte de los tutores resulta muy difícil ya que dicho tedioso proceso
es realizar la búsqueda página por página del establecimiento educacional, por
ende toma mucho tiempo. Además resulta muy difícil que los tutores tengan el
conocimiento total sobre los establecimientos educacionales que se encuentren
dentro de un rango de kilómetros respecto a su hogar.
En el anexo se encuentra al final de este documento se halla una encuesta
que fueron realizadas a los tutores o padres. Estas encuestas que tienen como fin
evaluar la necesidad de lanzar un nuevo producto al mercado según las
necesidades de los tutores. Las encuestas realizadas nos proporcionaron con
números que existe tal necesidad por parte de los padres o tutores. Parte de los
resultados obtenidos avalan la necesidad planteada generando un problema para
los tutores. Las encuestas son de gran utilidad para nosotros, debido a que no se
tiene un cliente especifico, es que a través de nuestro Fan Page en la red social
Facebook (www.facebook.com/Faceschool) las encuestas nos permite abarcar
mas stakeholders, lo que en definitiva nos proporciona saber de manera
fehaciente que es lo que quiere los padres. Además nuestro Fan Page nos
proporciona un feedback entre el equipo y la comunidad, ya que constantemente
se están subiendo noticias respecto a nuestro proyecto.
9
2.9.2 Situación Actual
Hoy día en los padres poseen distintas formas para buscar colegios para
sus hijos, ya sea buscando por internet, yendo personalmente a cada colegios que
desea ver o por su propio conocimiento.
Los tutores o padres son los encargados de revisar colegio por colegio en
internet la información relevante por ellos y si es que cumplen dicho requisito el
padre puede tomar la decisión de ir a visitar el colegio o reunirse con el encargado
para que finalmente le entregue la información pertinente. Dicho esto el tutor está
capacitado para tomar la decisión de matricular o no a su hijo.
El ir en búsqueda de nuevos proyectos sin lugar a duda genera
conocimientos a través de la innovación y creatividad, ya sea entregando un
nuevo servicio o mejorando uno existente con un único fin: tener éxito en el
mercado.
La tecnología en conjunto con internet resulta esencial para realizar una
búsqueda. Una búsqueda no resulta tan fácil si no se tienen las herramientas
adecuadas para realizarla y obviamente se dificulta mucho más si se tiene
desconocimiento de lo que se está buscando. Es por esto que resulta un proceso
engorroso y tedioso el buscar un establecimiento educacional a nuestros hijos.
Hay muchas preguntas que uno debe contestar antes como por ejemplo:
¿Qué tipo de colegio busco? ¿Privado? ¿Municipal?, o ¿qué tan cerca estará el
colegio de mi casa? Son preguntas básicas que a la hora de buscar un colegio
resulta muy importante responderlas. Es importante saber que mientras mayor
información se tenga respecto al colegio, la decisión de los padres o tutores será
la mejor, ya que tomaran esa decisión informados y teniendo un claro
conocimiento sobre el colegio en donde matricularían a sus hijos/as.
Este trabajo se divide en 5 capítulos en los cuales podemos nombrar una
breve descripción de los puntos más relevantes de cada uno.
Capítulo I: En este se capítulo se realiza una presentación clara, breve y
10
precisa del contenido que se desarrolla en este documento, y se indican las
razones por las cuales se decidió abordar el problema. Se indica cuál es el
problema abordado, qué objetivos se persiguen, cual es el alcance, limitaciones
y supuestos.
Capítulo II: Este capítulo tiene por finalidad determinar la situación actual,
un análisis de la situación y la dirección de cambio.
Capítulo III: En
base a la propuesta en el
capítulo anterior. Se
pretenderá justificar la metodología a aplicar. A partir de ese punto, aplicando la
metodología definir cómo se ejecutarán las disciplinas de apoyo al desarrollo y
gestión de este proyecto: control de configuración,
control
de
cambios y
proceso de control de riesgos.
Capítulo IV: Este capítulo se muestra las tareas realizadas según el
plan de proyecto.
Capítulo V: Las preguntas guías de este capítulo son: ¿Qué se hizo?,
¿Se logró resolver el problema? Y un análisis de los futuros desarrollos y
crecimientos del proyecto.
11
Capitulo II
2.10
Fundamentación del Tema
2.10.1 Problema
Como se puede apreciar en nuestro diagrama causa-efecto (Figura Nº1), el
problema nace a partir de la desinformación por parte de los padres a la hora de
buscar colegios a sus hijos. Lo cual es producido por las fuentes de comunicación
que existen ya que no se establece una comunicación directa con el colegio al
momento de contactarse con uno, y no existe un sitio donde se encuentren todos
los colegios. Por otro lado tenemos nos encontramos con que el personal del
colegio no se encuentre disponible al momento de que uno quiera contactarse con
ellos. Luego tenemos al colegio el cual no siempre entrega toda la información o
colegios de escasos recursos no posean alguna página web donde puedan
publicar su información. Y podemos encontrarnos con que el tutor del alumno
tenga un desconocimiento de los colegios de su región.
Cinco Por que
Existe una desorganización de la información sobre los colegios en la web
1 ¿Porque existe una desorganización de la información?
Porque no se encuentra toda la información en un solo sitio web
2 ¿Porque no se encuentra la información en un solo sitio web?
Debido a que no existe una agrupación de todos los colegios
3 ¿Porque deberia existir una agrupación de todos los colegios?
Para asi poder informar a los padres sobre los colegios.
4 ¿Porque se debe informar a los padres sobre los colegios?
Para que puedan tomar una decisión informada acerca del colegio donde
12
matriculara a su hijo
5 ¿Porque los padres deben tomar una decisión informada?
Para no seleccionar un colegio erróneo para su hijo.
Diagrama Causa – Efecto
Figura 1: Causa - Efecto
13
2.10.2 Objetivos
2.10.3 Objetivo General
•
Reducir en un 15% las decisiones erróneas de los padres al momento de
seleccionar el colegio.(OG)
2.10.4 Objetivos Específicos
•
Concentrar como mínimo un 80%(320) de los colegios de la zona. (Total en
región de Valparaíso = 401 colegios).(OE1)
•
•
La información de los colegios estará como máximo desactualizada en un
mes.(OE2)
•
La información para tomar la decisión de selección doble de un colegio
debe estar disponible en menos de un min.(OE4)
2.10.5 Alcance
2.10.6 Alcance del Proyecto
Con el fin de cumplir el objetivo, este proyecto lograra brindar una mejor
información sobre los colegios de la zona, la cual proporcionará un recomendador
de colegios a través de filtros e información relevante a partir de la
geolocalización.Esto incluye:
•
Mostrar al usuario la mayor cantidad de colegios de la zona que este
se ubique dentro de un radio determinado.
•
En segundo lugar, proporcionara la información relevante del colegio.
•
En tercer lugar, proporcionara un comparador de colegios.
•
En cuarto lugar, tendrá un tiempo de respuesta inferior a 1 min
(*condiciones ideales).
14
2.10.7 Supuestos
•
Se pretende contar con la información proporcionada por la página web
del Ministerio de Educación (www.mineduc.cl), la cual nos permitirá obtener
información verídica correspondiente a cada colegio.
2.10.8 Restricciones
1. No funcionará los días que se realice mantención.
2. No funcionará la geolocalización si no se pudo determinar su
localización.
3. No funcionará sin conexión a internet.
4. La búsqueda no se realizará a través de voz, sólo según criterios
definidos.
15
2.10.9 Modelo Canvas
A continuación se presentará el modelo
Lean Canvas (Tabla Nº3) un
modelo de negocios que ayuda a diseñar e innovar sobre nuestro modelo de
negocios. Esta herramienta nos ayuda a asegurar el desarrollo de un modelo de
negocio claro y consistente, capaz de ofrecer las respuestas indicadas a las
necesidades comerciales, lo que permite eliminar el desperdicio que se produce
desarrollando un producto que finalmente no es requerido o no era lo que
solucionaba el problema, lo que se genera por el desconocimiento de las
verdaderas necesidades del cliente. Este modelo que trata de mezclar el modelo
Canvas tradicional y el método Lean Startup, resulta vital a la hora de abordar un
lanzamiento de un negocio y producto. El modelo Lean Canvas resulta tener un
enfoque hacia entender el problema para luego realizar el producto.
Tabla 1:Lean Canvas
16
La finalidad de mostrar nuestro Lean Canvas es poder definir claramente
nuestra área de negocio que a partir de los 9 ítems se puede apreciar hacia donde
apuntamos mostrando como lo haremos. Por ejemplo nuestro segmento de
clientes está definido para tutores o padres que vivan en la V regiones de nuestro
país que tengan hijos entre 5 y 17 años.
2.10.10 Mercado existente
Nuestra
competencia
directa
son
páginas
web
que
proporcionan
información sobre colegios, los cuales los explicaremos a continuación:
http://www.colegiosymatriculas.cl/
Es una página en la cual asesoran para encontrar la mejor alternativa de
colegio para matricular al hijo, no muestran ningún colegio, si no que uno les envía
la información del colegio que uno desea averiguar y ellos averiguan lo que uno
desea saber y se vuelven a contactar con uno.
http://www.educarchile.cl/
Es una página que está dirigida a todos los miembros de la comunidad
educativa nacional, que tiene como misión contribuir en el mejoramiento de la
calidad de la educación en todos sus niveles, ámbitos y modalidades, ampliando
las oportunidades de formación y aprendizaje a lo largo de la vida.
Si bien estas páginas son útiles a la hora de querer saber información sobre
colegios, estas no resultan ser eficientes. La finalidad de describir nuestra
competencia, es debido a que cada una de ellas presenta defectos y grandes
debilidades a la hora de poder compararla con nuestra página Faceschool. El
objetivo es demostrar que no hay nada realmente en el mercado que cumpla con
las cualidades que se presentan a continuación por ende resulta un proyecto
innovador.
17
Figura 2: Competencias
En la figura Nº2 se pueden apreciar las competencias existentes, en donde
el fin de esta matriz es analizar a través de ciertas características esenciales que
fueron determinadas a partir de la encuesta que se le realizaron a los padres. Las
características que se encuentran en la primera fila y las aplicaciones que se
encuentran en la primera columna, van descritas por un ticket y una cruz. El primer
símbolo corresponde a que cumple satisfactoriamente dicha característica, en
cambio el segundo símbolo describe que no cumple dicha característica. En
primer lugar se tiene la información de los colegios en donde obviamente debe
aparecer una información respecto al colegio buscado, además siendo una
información verídica y útil para el buscador. El segundo criterio se tiene un
comparador, en donde a partir de la información de los colegios seleccionados,
permite entregar un comparador mostrando información de colegios. El sistema de
ubicación y ruta permite que nos ubique en el mapa y nos muestre la ruta más
cercana hacia el establecimiento que nosotros seleccionamos. El cuarto indicador
llamado contacto directo es la posibilidad de mandar un mensaje directamente
desde la aplicación hacia el encargado de matrículas del establecimiento. Y
finalmente el buscador bajo criterio en donde el realizar la búsqueda se dará bajo
ciertos criterios seleccionados. Sin lugar a duda Faceschool cumple con dichas
características esenciales que fueron obtenidas como importantes dentro de la
18
encuesta realizada por lo que nos garantiza que nuestro producto será una buena
herramienta.
2.10.11 Alternativas de Solución
1. Realizar una oficina de consultas donde se maneja la información de todos
los colegios.Esta alternativa surge como opcion debido a que se puede
habilitar una oficina en donde se mantenga conocimiento de la informacion
relevante de los colegios.La informacion podra ser adquerida por cada tutor,
para que éste finalmente se encuentre informado respecto a cada
establecimiento educacional.
2. Reunir todos los colegios en un solo lugar. Anexar todas las páginas web
de los colegios.Esta idea surge como necesidad a concentrar la mayor
cantidad de colegios en un solo lugar,es por eso que a través de una
página web en donde se enlisten la mayor cantidad de colegios con sus
respectivas páginas Web,pudiendo así el usuario ir ingresando a cual le
parezca pertinente.
3. Reunir todo los colegios en un solo lugar, agregando geolocalización,
comparador
y
buscador
además
de
información
sobre
los
colegios.Logrando concentrar gran cantidad de colegios con la información
que la gente necesita para tomar una decisión.Sin lugar a dudas agregar un
recomendador para dicha solución resulta vital,mostrando a partir de
conexiones con su círculo de personas
los colegios que éstos hayan
recomendado.
2.10.12
Solución Propuesta
Como propuesta y teniendo conocimiento del problema se propone la
creación de una página web que proporcione información de los colegios donde el
usuario decida buscar,comparar y recomendar para que así los padres puedan ver
las mejores alternativas.Existen grandes ventajas al seleccionar esta solución, una
de ellas resulta ser la geolocalización en donde a partir de la ubicación del usuario
19
lo ubicará y mostrará la mayor cantidad de colegios disponibles a su alrededor con
sus respectivas distancias y ruta más cercana para llegar a él. Además al realizar
una búsqueda se podrá realizar a través de filtros, para que finalmente a partir de
un recomendador el sistema muestre los colegios con mayor calificación que otros
usuarios podrán realizar.
2.10.13 Esquema de solución
En el siguiente esquema (Figura N°3) se puede apreciar el esquema de
solución en el que se aprecia al cliente ligero el cual usando algún navegador, que
puede ser Chrome, Mozilla o Internet Explorer, se conecta a través de http en
donde este se conecta a la api de google, el cual a partir de la IP del usuario
puede determinar su ubicación, y a su vez este se conecta a Faceschool en donde
el servidor procesa las consultas masivas, que se le realizan por medio de SQL a
la base de datos. Otro caso, sería si el cliente ligero se conectará a través de
algún navegador ya mencionado pero utilizando la conexión a internet por medio
de su smartphone en donde la ubicación se obtendrá a partir del GPS que este
posee.
Figura 3: Esquema Solución
20
2.10.13 Factibilidad
Factibilidad Técnica
La factibilidad técnica consistió en realizar una evaluación de la tecnología
existente y de los conocimientos del equipo de desarrollo, este estudio estuvo
destinado a recolectar la información sobre los componentes técnicos que se
poseen y la posibilidad de hacer uso de los mismos en el desarrollo e
implementación del sistema y de ser necesario, la adquisición de otros
requerimientos tecnológicos. El resultado del estudio nos indicó que la tecnología
necesitada en este proyecto se encuentra ampliamente disponible, ya sea tanto la
tecnología de servidores y computadores, los cuales hoy en día son de grandes
características.
Factibilidad Operacional
Permite a todos los usuarios conocer la posibilidad de utilizar las nuevas
tecnologías que se utilizan en páginas web, aprovechando los beneficios que
ofrece, por otra parte, el correcto funcionamiento y uso de Faceschool, estará
limitado a la capacidad de los usuarios que utilicen la página.
Factibilidad Económica
A continuación se presenta el resultado del análisis de las cotizaciones
realizadas para Faceschool, en cuanto a costos de hardware, software y recursos
humanos:
21
● Software:
Descripción
Subtotal
Sublime Text 3 para 3 programadores
con licencias compatibles para
Windows 8.1
$128.597
Sistema operativo Windows 8.1
$268.590
Microsoft Office 2013
$202.384
Subtotal
$599.571
● Recursos Humanos
Cantidad
Personal
Horas
Salario
Mensual
Totales
2
Programador
6
$600.000
$1.200.000
1
Analista
6
$800.000
$800.000
1
Encargado de
Pruebas
6
$400.000
$400.000
Subtotales
$2.400.000
* Notas:
- Son 2 programadores, lo que implica un costo total mensual por programador de
$600.000.
- El encargado de pruebas, verificará el correcto funcionamiento del programa una
vez que ha sido concluido, por lo que su salario es de 15 días.
- El salario del personal fue obtenido por medio de consulta a gente experta en el
campo.
22
● Hardware
Cantidad
Descripción
Precio Unitario
Totales
2
Notebook hp envy
dv4
$450.000
$900.000
$40.000
$40.000
1
Multifuncional Hp
C4780
Subtotales
$940.000
A partir del estudio de la factibilidad económica Faceschool se financiara
cobrando una membresía anual de un pago mensual de $10.000 por colegio para
aparecer en nuestro sitio.
2.10.14 Factores de Éxito
Dentro de los factores de éxito del proyecto Faceschool destacan:
·
Que el tiempo se cumpla según la planificación influirá en las probabilidades de
éxito del proyecto.
·
Que los costos asociados al proyecto estén dentro del presupuesto.
·
La fuente Mineduc se encuentre siempre disponible.
·
Que el sistema tenga como mínimo 30 usuarios.
23
2.10.15
Situación Futura
En el momento de implementar Faceschool, utilizando este servicio,
pudimos reducir en un 20% el total de decisiones erróneas de los padres al
momento de matricular a sus hijos. Es por eso que nuestro servicio Faceschool se
podría considerar una herramienta útil para aquellos padres que buscan una
educación de calidad para sus hijos, puedan tomar una decisión en base a la
información. Entregando a los padres información oportuna y que este proceso
sea lo menos tedioso posible para ellos.
24
Requerimientos No Funcionales
Definición: son las especificaciones puntuales sobre el sistema o SW que
vienen a ser las necesidades del negocio, describe los servicios que deben ofrecer
el sistema y sus restricciones.
A continuación se detallan los requisitos no funcionales identificados para el
presente proyecto:
Identificación
Título
Alta.
Media.
RNF-1
El sistema debe compatible con
cualquier Sistema Operativo
(SO), inclusive accediendo
desde un SO movil.
El sistema debe ser compatible
con Firefox* , Chrome* y
Internet Explorer*.(* Según
versión)
Media.
Alta.
Alta.
Alta.
RNF-2
RNF-3
El sistema deberá poder funcionar con
a lo menos 49 usuarios conectados en
forma simultánea.
importancia Complejidad
RNF-4
El sistema deberá tener una
disponibilidad del 98%*(*a excepción
cuando se haga mantenimiento)
Media.
Alta.
RNF-5
El sistema debe ser usable según
ISO
Media.
Alta.
9126 y 9241.
Tabla 2: Requerimientos No Funcionales
25
2.10.16
Faceschool: Alto Nivel
La vista 4+ 1 de Krutchen permite ayudar a los desarrolladores del software a
mantener un esquema estructurado del software facilitando a la creación del
mismo. Lo importante de estas vistas es enfocar el mismo software de diferentes
aspectos, las cuales representan diferentes aspectos y características del
software.
A partir de las siguientes imágenes queremos dar a conocer la solución
propuesta. Dichas imágenes permiten aclarar o describir cómo será la página web.
En la figura Nº4 se puede apreciar nuestro diagrama de componentes el
cual consta de seis componentes principales que son el landing, administración,
mapa, colegio, config y el recomendador. Cada componente posee un sub
componente como lo es por ejemplo en el caso de la administracion se conforma
de tres subcomponentes, Login.php, inicio.php y modificar.show.
26
Figura 4 : Diagrama de Componentes
27
A continuación se detalle el diagrama de despliegue de nuestro proyecto.
Básicamente está compuesto por un navegador web un servidor que consta del
servidor apache/php y una base de datos MySQL, en donde el servidor se conecta
a través de HTTP con el api de google maps.
Figura 5: Diagrama de Despliegue
A continuación se mostrará los diagramas de secuencia esta vista tiene
como función describir la secuencia lógica de las funcionalidades.
28
En esta figura se puede apreciar la funcionalidad de ver ruta. El usuario
ingresa a nuestra página web en donde de manera automática se cargan los
colegios. El usuario deberá seleccionar un colegio para que finalmente el servidor
devuelva la información a la interfaz, en donde aparecerá en un mapa la ruta más
cercana hacia el colegio seleccionado desde su ubicación.
Figura 6: Diagrama de Secuencia Ruta
29
En la figura Nº7 se puede apreciar la funcionalidad de búsqueda por
criterio. Esta funcionalidad se inicia con el usuario en donde deberá seleccionar
los criterios bajo los cuales se desea realizar la búsqueda para que finalmente el
servidor devuelva los resultados obtenidos a partir de los filtros seleccionados.
Figura 7: Diagrama de Secuencia Búsqueda por Criterio
30
En la figura Nº8 se puede apreciar la funcionalidad ver información del
colegio. Esta funcionalidad se inicia con el usuario en donde deberá seleccionar el
colegio para que finalmente el servidor devuelva la información que se tenga
respecto a este colegio, a la interfaz.
Figura 8: Diagrama de Secuencia Información
31
En la figura Nº9 se puede apreciar la funcionalidad de comparador. Esta
funcionalidad se inicia con el usuario en donde deberá seleccionar dos colegio e
para que finalmente el servidor devuelva los resultados obtenidos a partir de la
información de los colegios.
Figura 9: Diagrama de Secuencia Comparador
32
En la figura Nº10 se puede apreciar la funcionalidad de ingresar colegios.
Esta funcionalidad se inicia con el usuario en donde deberá ingresar un usuario y
contraseña, si estos resultan ser correctos el administrador podrá ingresar un
colegio llenando los campos. Finalmente se devuelve un mensaje que despliega si
la operación se realizó con éxito o no.
Por otra parte, se puede apreciar la funcionalidad de modificar colegios
(Figura Nº10). Esta funcionalidad se inicia con el usuario en donde deberá
ingresar un usuario y contraseña, si estos resultan ser correctos el administrador
podrá modificar algún campo del colegio. Finalmente se devuelve un mensaje que
despliega si la operación se realizó con éxito o no.
Y finalmente, se puede apreciar la funcionalidad de eliminar colegios. Esta
funcionalidad se inicia con el usuario en donde deberá ingresar un usuario y
contraseña, si estos resultan ser correctos el administrador podrá eliminar un
colegio. Finalmente se devuelve un mensaje que despliega si la operación se
realizó con éxito o no.
33
Figura 10: Diagrama de Secuencia Administrar Colegio
34
Vista de Escenario (Historias de Usuario)
Identificación
Nombre
HU1
Ruta
HU2
Login
HU3
HU4
HU5
Visitas
Reclamo
Gestionar Info.Sitio
Descripción
E1: Como Usuario quiero
ver la ruta para llegar al
colegio, en donde la ruta
sea la más cercana.
E2:Como Usuario quiero
ver la ruta para llegar al
colegio, mostrándome la
distancia en KM.
E1: Como Administrador
quiero poder ingresar a
través de un usuario y
contraseña para poder
realizar actualizaciones a
la información de los
colegios.
E1: Como Administrador
quiero poder gestionar la
visitas a los colegios
realizada por los usuarios
para poder vender la
información obtenida,
generando un informe
con la información de:
cantidad de visitas,
tiempo de visitas,
mensajes enviados a
través del sitio Web.
E1: Como usuario quiero
poder ingresar un
reclamo para poder tener
conocimiento de los
problemas de la página.
E1: como Administrador
quiero poder gestionar la
información del sitio para
así poder ingresar,
modificar o borrar un
establecimiento
educacional de la base
35
de datos.
HU6
HU7
Mensaje
Mapa
HU8
Información
E1: Como usuario quiero
poder enviar un mensaje
para mantener un
contacto o poder
realizarle consultas al
encargado del colegio
visitado.
E1: Como usuario quiero
poder ver un mapa
donde se encuentran la
mayor cantidad de
colegios cercanos a mi
ubicación para así poder
ver la distancia que hay.
E1: Como usuario quiero
poder ver la información
relevante de los colegios
para así poder tomar una
correcta decisión.
36
Para finalizar se muestra el diseño de la Base de Datos en donde se puede
apreciar un total de 16 tablas. Cada una de ellas con sus respectivas claves
primarias y claves foráneas.
Figura 11: Diagrama de Clases
37
Capítulo III
2.11 Materiales y Métodos
2.11.1 Fundamentación de la Metodología
Dirigir un proyecto no es fácil, y es por ello que existen distintas
metodologías para realizar este procedimiento.
La dirección de proyecto se define como la aplicación de conocimiento,
habilidades, herramientas y técnicas a las actividades del proyecto para cumplir
con los requisitos del mismo. Todo proyecto cuenta con las siguientes fases
Iniciación, Planificación, Ejecución, Seguimiento y Control y Cierre. Para dirigir un
proyecto se emplean diferentes metodologías para abordar la Gestión del
Proyecto y el Desarrollo del Proyecto.
Para cualquier proyecto es necesario disponer de una gestión eficiente para
así garantizar que el proyecto cumpla con los objetivos y que se desarrolle dentro
de lo planificado. Es entonces que la gestión tiene como fin planificar y controlar el
desarrollo de un sistema con un costo mínimo dentro de un periodo definido
cumpliendo finalmente con el alcance del proyecto. Para definir la metodología
que se necesita emplear para la gestión del proyecto, dependerá de ciertos
factores del proyecto y del cliente. En donde cada metodología que se empleara
tiene características especiales y fundamentales para ocuparlos.
Nuestro proyecto se gestionará bajo la metodología Scrum. Scrum es un
marco de trabajo para la gestión y desarrollo de software basada en un proceso
iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo
ágil de software. Dentro de las características de Scrum destaca la estructura de
organización del equipo donde todos poseen sus cargos claramente definidos. A
partir de las características principales que posee Scrum es que decidimos
utilizarlo. Una de esas razones es debido a que el mercado actual es altamente
competitivo y la tecnología es muy cambiante, lo que hace que para el desarrollo
de un software se pida básicamente rapidez, calidad y reducción de costes, y es
38
entonces que para asumir dichos retos es necesario ocupar una metodología que
nos entregue agilidad y flexibilidad a nuestro proyecto, pues claramente nuestro
proyecto al ser tan tecnológico resulta vital ocupar una gestión ágil y flexible. El
hecho de ir trabajando por Sprints nos permite ir entregando pequeñas porciones
del software a partir de aquellas funcionalidades que entreguen más valor al
negocio, lo cual nos permite ir entregando semana a semana un avance
completamente funcional de nuestro proyecto. Dichos avances que son
planificados a través de un Sprint Backlog. Además su flexibilidad y adaptación
antes las nuevas prioridades que pueda surgir al negocio es algo que nos llamó la
atención debido a que en todo proyecto pueden haber cambios y sobre todo en las
prioridades.
Por otro lado la metodología de desarrollo será Extreme Programing
(Programación Extrema o XP), en donde nos sentimos completamente seguros
que va a ser la metodología adecuada para nuestro proyecto en base a una
investigación que nosotros realizamos a partir de las características de nuestro
proyecto.
Las características principales de XP se adecuan perfectamente a nuestro
proyecto porque: una planificación incremental nos permite al equipo ir
desarrollando pequeños incrementos a partir de las historias de usuario que más
valor entreguen al negocio, lo que nos permite ir mejorando en cada iteración
minimizando el riesgo de errores en el código, además de ir permitiéndonos
acomodarnos de manera muy fácil a la cronología impuesta por la Universidad
respecto a los hitos, ya que para cada hito proporcionaremos un incremento de
nuestra aplicación logrando así, que a final de año se acerque al resultado ideal
esperado. Además el ir por incrementos nos facilita ir mostrándole pequeñas
partes o porciones de la aplicación a nuestro Product Owner (PO).
De igual manera características como programación en parejas se adecua a
nuestro proyecto claramente ya que somos solo dos personas las que nos
encontramos desarrollando este producto. Esto nos permite que el código cuando
se está escribiendo es revisado y discutido a pesar de la posible pérdida de
productividad inmediata. Además esto fomenta a la comunicación del equipo de
39
trabajo promoviendo la relación entre los miembros del equipo, en donde el estar
acompañado en alguna situación crítica podrá favorecer a no quedar estancados
complementando los conocimientos y posiblemente acelerar el proceso de
codificación.
2.11.2
Metodología de Desarrollo
Según Kent Beck:” un proceso ligero, de bajo riesgo, flexible, predecible,
científico y divertido de desarrollar software”.
Figura 12: Fases de Programación Extrema
A partir de la figura Nº12 explicaremos y describiremos como vamos a
utilizar en nuestro proyecto esta metodología de desarrollo.
La fase de Pre Juego, se compone principalmente de dos actividades en las
cuales se encuentran las historias de usuario y el release planning.
40
Las historias de usuario que en definitiva es una representación de las
necesidades del negocio, son escritas por los clientes. Si bien en la metodología
de gestión nuestro Product Owner es quien representa este cliente, y es por ello
que con los profesores a cargo del ramo Proyecto de Título, se describieron tales
historias de usuarios. Dichas historias de usuario se describieron en una plantilla
Excel, con sus respectivas pruebas de aceptación.
El release planning resulta luego de haber realizado las historias de usuario,
y básicamente se realiza y se organiza que historias de usuario se realizaran para
cada incremento. Dicha tarea nosotros la establecimos en el Product Backlog en
donde se encuentran todas las HU (historias de usuario), describiendo en que
iteración se realizaran dichas HU. Dichas historias de usuario tienen que ser
medibles e incluso si estas son muy extensas es necesario dividir dicha HU,
desglosándola en pequeñas actividades, de esta forma es esencial para que se
tenga una noción del sprint entregar una estructura de desglose de trabajo.
El diseño es otro punto importante en la metodología XP, si bien al ser una
metodología ágil, el objetivo no es obtener un diseño muy detallista, sino más que
nada lo esencial para cumplir con el funcionamiento de la historia de usuario que
se realizara. Dichos diseños bosquejos simples se están realizando en Mockups,
un programa fácil de utilizar que nos da la posibilidad de hacer diseños
rápidamente. Otro punto son los diseños de las pruebas que se realizaran para
cada Sprint (revisar Plan de Pruebas), pero para esto se realizaran plantillas de
Excel, en donde se podrán diseñar rápidamente como se realizaran y cuáles serán
los criterios de aprobación de dichas pruebas. Además los riesgos se llevaran en
una plantilla Excel que será revisada día a día, entregando un detalle claro en
gráficos sobre qué riesgo incremento, apareció o disminuyo.
La codificación es algo esencial como bien lo dice XP, la codificación se
está realizando en parejas. Si bien puede perder cierta productividad, el fin de
programar en parejas trata de solventar dudas de programación que uno u otro de
los desarrolladores presente. Dicha codificación se realiza en un solo computador
con las herramientas de desarrollo que se especificaran más adelante.
41
2.11.3
Metodología Gestión del Proyecto
En nuestro proyecto utilizamos la metodología Scrum, modelo de referencia
que define un conjunto de prácticas y roles que puede tomarse como punto de
partida para definir el proceso de desarrollo que se ejecutara durante un proyecto.
Figura 13 : Concepto Scrum
En la figura Nº13 se puede apreciar claramente los artefactos que se
realizan en Scrum. Scrum está formado por Sprints que son cada una de las
partes del ciclo de vida de la metodología, en donde cada sprint dura entre 2 a 4
semanas. Para nuestro proyecto los Sprints dependen de las historias de usuarios
que queramos abarcar, es decir, la HU Nº1 que se abarca en el primer Sprint 1
que tiene una duración de 3 semanas, en cambio en el Sprint 2 que se abarca la
HU Nº2 y Nº3 dura 4 semanas. Si bien no es aconsejable cambiar la duración de
los Sprints esto se realiza debido a una expresa petición de nuestro Big Boss,
42
concluyendo que a partir del Sprint Nº3 la duración de los Sprints será de dos
semanas. El Product Backlog es una lista con las necesidades del cliente sobre el
producto. Para producir dicho Product Backlog se ocupa la herramienta de Excel,
en donde a partir de las historias de usuario se ordena y prioriza según el PO.
Dicho Product Backlog es esencial para producir el Sprint Backlog ya que del
Product Backlog nacen las actividades que se documentan en el Sprint Backlog. El
Sprint Backlog es un documento detallado donde se asignan las tareas al equipo,
destinando una cierta cantidad de duración en horas. Dicho documento cumple
con una identificación del sprint, identificación de la tarea, descripción básica de la
tarea, persona responsable, tiempo y estado de la tarea.
Sprint Planning Meeting son reuniones que se realizan antes de cada sprint
en donde tiene como objetivo seleccionar y planificar el trabajo que se desarrollara
en ese Sprint. Dichas reuniones que se realizan, antes de cada sprint se realizan
en la Universidad, en donde la duración no son más de 2 horas. Si bien son
reuniones cortas, lo que trata de abarcar es que se hará para dicho Sprint.
Además existen las reuniones llamadas Scrum daily meeting. Estas reuniones
diarias que se realizan cuando ya se está en un Sprint, se realiza para facilitar la
transferencia de información y la colaboración entre los miembros del equipo.
Dichas reuniones que se tienen durante el desarrollo de los sprint se realiza
presencialmente además apoyándonos de la conocida Scrum Task Board, la cual
trabaja bajo conceptos claves sobre las tareas, asignándolas estados; To Do, In
Process, To Verify, Done. Estas reuniones se realizaran en nuestro proyecto antes
de cada Sprint definiendo las tareas a realizar en dicho sprint, aparte de las que se
realizan diariamente. Las reuniones diarias se realizara aproximadamente en 10
min, preguntando que tereas se realizaron, que falta por hacer y que tareas se
están realizando, entregando un feedback entre el equipo.
El Sprint Review que se realiza al final de cada Sprint se podría enfocar en
nuestro Proyecto, como el feedback que obtenemos de los profesores guías
respecto a nuestro incremento del producto funcional mostrado. En nuestro caso
dicho Review toma un tiempo aproximadamente de 35 minutos. La finalidad es
43
poder contestar preguntas y describir como fue el proceso de realizar el
incremento del producto.
Para culminar se realiza el Sprint Retrospective una reunión entre el PO y el
equipo de trabajo, en donde como principal función es ver si el PO aprueba o no el
Sprint mostrado, si efectivamente el sistema era lo que él esperaba. Además se
analiza que cosas hay que mejorar o cuales fueron los errores cometidos durante
este sprint. El principal beneficio de esta reunión es aumentar la motivación del
equipo además de dejar al cliente realmente seguro sobre el sistema que se está
desarrollando.
2.11.4
Organigrama y Roles
A continuación se mostraran los organigramas y las responsabilidades de
cada uno los distintos roles que se cumplen tanto en Scrum como XP.
Figura Nº19 Organigrama Scrum
A partir de la figura Nº19 se pueden apreciar que existen tres grandes
divisiones al momento de responsabilizar a alguien. Estos son: el Product Owner,
44
Scrum Master, y Scrum Team. A continuación se detalla cada uno de ellos y sus
responsabilidades.
El Dueño de Producto (Product Owner)
El Dueño de Producto es la única persona autorizada para decidir sobre
cuáles funcionalidades y características funcionales tendrá el producto. Es quien
representa al cliente, usuarios del software y todas aquellas partes interesadas en
el producto.
Scrum Master
Es el que debe velar por los participantes del proyecto, debe encargarse de
formar y garantizar el correcto funcionamiento de la metodología.
Scrum Team
Es el
equipo de entre 4 a 9 personas encargados de desarrollar el
producto. En este proyecto son solo 2 personas que desarrollaran el proyecto.
En la tabla Nº3 se mostraran los responsables de nuestro proyecto
asociados a la metodología Scrum, en donde cada integrante asume las
responsabilidades previamente descritas según su rol.
45
Rol
Responsable
Product Owner
Gianina Acosta
Scrum Master
Fernando Figueroa
Scrum Team
Daniel Labra/Fernando
Figueroa
Tabla 3: Rol/Responsable
Gianina Acosta que tiene como cargo ser el Product Owner debe ejercer las
funciones descritas en la tabla Nº4, dichas funciones son esenciales para poder
dirigir un proyecto de la mejor manera posible, por ende el no cumplir dichas
funciones puede significar el fracaso del proyecto. El realizar esta tabla permite a
cada integrante responsabilizar a la persona a cargo y no a cualquier persona.
Responsable:
Responsabilidad que asume:
1. Debe definir las características
del producto.
2. Responsable del Product
Gianina Acosta
Backlog.
3. Estimar
el
financiamiento
necesario para el proyecto.
4. Ajustar
las
características
y
prioridades por Sprint.
46
5. Aceptar o rechazar los resultados
del
trabajo
provenientes
del
Scrum Team.
Tabla 4: Funciones PO
Las funciones que debe ejercer Fernando Figueroa como Scrum Master
están determinadas a partir de la tabla Nº5
Responsable:
Funciones que asume:
1. Garantizar la correcta aplicación
de Scrum.
2. Guiar al equipo a lo largo del
Fernando Figueroa
desarrollo.
3. Organizar las reuniones.
4. Resolver
los
entorpezcan
conflictos
el
progreso
que
del
proyecto.
Tabla 5: Funciones Scrum Master
Finalmente el equipo a cargo de desarrollar el proyecto debe ejercer las
tareas o funciones descritas en la tabla Nº6.
Responsable:
Funciones que asume:
1. Crear/desarrollar el producto.
2. Auto-asignación de tareas para
Daniel Labra y Fernando Figueroa
realizar el producto.
3. Estimar la complejidad de los
requerimientos del producto.
Tabla 6: Funciones Equipo Desarrollador
47
El organigrama asociado a la metodología de desarrollo XP (Programación
Extrema) está dividido en seis roles establecidos y claros, los que se basan en un
equipo pequeño de personas con habilidades complementarias que tienen el
mismo objetivo. A continuación se detallan los roles y responsabilidades que tiene
cada uno de ellos.
Rol
Programador
Responsable
Daniel
Labra/Fernando
Figueroa
Tracker
Fernando Figueroa
Coach
Daniel Labra
Consultor
Fernando Figueroa
Gestor
Daniel Labra
Tabla 7:Rol-Integrante
Desarrollador: Encargado de producir el código del sistema de la forma más
simple y definida que sea posible.
Responsable
Funcionalidad que asume
1. Escribir
las
pruebas
unitarias.
2. Estimar
Daniel Labra y Fernando Figueroa
las
historias
de
usuarios.
3. Desarrollar la aplicación.
Tabla 8: Funciones Desarrollador
48
Encargado de seguimiento (Tracker): Es el que proporciona la realimentación al
equipo.
Responsable
Funcionalidad que asume
1. Realiza
seguimiento
de
cada iteración.
2. Proporcionar
retroalimentación al equipo.
Fernando Figueroa
3. Supervisar el cumplimiento
de la estimaciones en cada
iteración
Tabla 9: Funciones Tracker
Entrenador (Coach): Es el responsable del proceso global.
Responsable
Funcionalidad que asume
1. Responsable del proceso
en conjunto.
2.
Daniel Labra
3. Intervenir directamente si es
necesario.
Tabla 10: Funciones Coach
Consultor: Si bien no es un miembro del equipo, es aquel que posee un
conocimiento puntual o específico dentro de un área concreta.
Responsable
Funcionalidad que asume
1. Apoyar al equipo XP en
situaciones puntuales.
49
Fernando Figueroa
Tabla 11: Funciones Consultor
Gestor (Big Boss): Es el vínculo entre clientes y programadores.
Responsable
Funcionalidad que asume
1.
Favorecer la relación entre
usuarios y desarrolladores
2. Cubrir las necesidades del
Oscar Pinto
equipo.
Tabla 12: Funciones Big Boss
A continuación se podría bosquejar un organigrama en donde demuestre
que ambas metodologías pueden y trabajan similarmente, en donde ciertos roles
son asumidos por uno u otro individuo.
En la figura Nº19 se puede apreciar como claramente ciertos roles se
asemejan debido a las responsabilidades y características que tienen cada uno,
como
por
ejemplo
el
Scrum
Master
tiene
las
mismas
cualidades
y
responsabilidades que un Coach en XP. Dicho organigrama es solo referencial y
nos permite identificar que los roles son prácticamente iguales.
Figura 14: Organigrama Scrum XP
50
2.11.5 Historias de Usuario
Identificación
HU1
Nombre
Ruta
Como
Quiero
Para
Usuario Ver la ruta Saber
para llegar distancia y el
al colegio. tiempo que
tomara.
Criterios de
aceptación
Resultado
Esperado
1.-Que sea la 1.-Poder apreciar
ruta más
en pantalla la ruta
cercana para el hacia el colegio
colegio
2.-Poder apreciar
2.-Distancia en la distancia.
KM
3.-Rango no
3.-mostrar
debiese ser mayor
colegios dentro a la 5ta región.
de un radio
seleccionado
por el cliente.
Prioridad Estimación(Puntos
Historia)
M
1
51
HU2
Login
Poder realizar 1.-Usuarios
Admin. Poder
ingresar a mantenciones. inválidos
través de un
2.-Contraseña
usuario y
Invalida
contraseña.
HU3
Visitas
Admin. Gestionar Poder vender
visitas a los la información
colegios
obtenida
realizada
por los
usuarios.
1.-Mensaje de
alerta respecto al
error
2.-Mensaje de
alerta respecto al
error
1.-Obtener la 1.-Se deberá poder
siguiente
generar un informe
información
con la información
sobre cada
de lo anteriormente
colegio:
detallado para
Cantidad de
cada colegio.
visitas,
cantidad de
veces
contactados,
cantidad de
matriculados a
través de la
página web,
tiempo de visita
por colegio en
la página web,
mensajes de
M
2
C
4
52
mejora sobre la
información del
colegio.
HU4
Reclamo
Usuario
Poder tener
conocimiento
de los
Ingresar un problemas de
la pagina
reclamo.
1.-Poder
ingresar un
reclamo sobre
la página web.
2.-los datos a
ingresar por
usuario son:
Nombre, Mail,
descripción.
1.-Poder obtener la
información del
reclamo, nombre,
mail, descripción
reclamo).
2.Validar el ingreso
de los datos
alertando con un
mensaje en el caso
de no haber
rellenado algún
campo.
C
1
53
HU5
Gestionar
Info.Sitio
Admin. Gestionar Ingresar,
información borrar y
del sitio.
modificar
colegios del
sitio
1.-Campos
1.- Mensaje de
vacíos al
alerta
ingresar, borrar correspondiente
y modificar
2.-Mensaje de
2.-Mostrar
alerta
mensaje
correspondiente
cuando se
3.-Mensaje de
agrega,
advertencia.
modifica o
elimina.
3.-Mostrar
mensaje de
advertencia al
eliminar
colegio.
M
4
HU6
Mensaje
Usuario Enviar un Mantener
mensaje al contacto con
contacto del la persona a
colegio
cargo del
seleccionad colegio y
o.
generar una
posible
reunión.
1.-Ingresar
datos del
usuario:
Nombre, mail,
telefono, curso
que se desea
ingresar y
descripción.
2.-Validar que
el mail haya
sido enviado
enviando copia
al mail del
tutor.
3.-Validar que
M
3
1.-Mensaje de
alerta al no llenar
algún campo.
2.-Mensaje de mail
enviado.
3.-Mensaje al
usuario de que el
mail fue recibido
por el personal
encargado del
colegio.(*por
validar)
54
el mail haya
llegado al
destino
(persona
colegio).
HU7
Mapa
Poder apreciar 1.-Obtener mi
Usuario Ver un
mapa
la distancia
ubicación.
donde
que hay desde 2.-Apreciar los
aparezca mi mi ubicación colegios que
ubicación y hacia los
hay en la V
la de los
colegios
región
colegios.
1.-Mostrar con
icono mi ubicación.
2.-Destacar los
colegios que se
encuentren en la V
región con un icono
y su nombre en él.
M
2
55
HU8
Poder tomar 1.-Informacion
Informació Usuario Que
aparezca una mejor
relevante.
n
información decisión
2.-Informacion
relevante de respecto a la actualizada.
los colegios. información de 3.-Informacion
otros colegios. verídica.
HU9
Búsqueda
Para realizar
Usuario Ingresar
criterios
búsqueda
para
acuerdo a mis
realizar una necesidades.
búsqueda
de colegios.
1.-Poder apreciar
la información del
colegio.
2.-Informacion
según la página del
Mineduc.
3.-La información
desplegada será
información
proporcionada por
el Mineduc.
M
2
1.-Poder
1.-Se deberá poder
seleccionar
seleccionar más de
más de un filtro un filtro para
2.-Actualizar
realizar la
mapa según
búsqueda.
filtro
2.-El mapa será
3.-Filtros
actualizado cada
relevantes
vez que se
busquen colegios a
través del filtro
3.-Propuestos por
el PO
M
3
56
HU10
Recomend Usuario Que el
sistema me
ador
recomiende
el mejor
colegio.
Para poder
tomar la
decisión en
base a la
recomendació
n
1.-Poder
1.-Se deberá poder
seleccionar uno seleccionar uno o
o más filtros. más filtros
2.-Actualizar
mostrando los
Recomendador colegios con mayor
según filtros. “me gusta” según
3.-Recomendar filtros.
según cantidad 2.-El
de "me gusta". Recomendador
Agregar
será actualizado
criterios de
cada vez que se
calidad.
busquen colegios a
través del filtro.
3.-Se mostraran los
colegios con mayor
cantidad de me
gusta de forma
descendente.
M
4
57
HU11
Circulo
Usuario
Para poder
1.-Poder
1.-Se deberá poder
Usuario Que el
sistema
saber los
seleccionar los ajustar los metros a
muestre un colegios que metros a la
la redonda, en
círculo
hay a la
redonda.
donde el círculo
ajustable en redonda de mí 2.-Cambiar
máximo no deberá
metros en ubicación
color del icono exceder el porte de
mi
forma de filtrar del colegio al la V región.
ubicación. colegios.
estar dentro del 2.-Se deberá
círculo.
cambiar el color del
3.-No
icono (de color
mostrar/ocultar negro a verde)
los colegios
cuando el colegio
que están fuera se encuentre
del circulo
dentro del círculo.
establecido.
3.-Se deberá
ocultar los colegios
que no se
encuentren dentro
del círculo,
aparecerán solo los
colegios dentro del
círculo.
M
2
58
HU12
Ocultar
Colegios
Usuario Que el
sistema
oculte el
resto de
colegios
cuando se
selecciona
la ruta de
cómo llegar
a un
colegio.
Para poder
visualizar
claramente la
ruta hacia el
colegio
seleccionado.
1.-Cambiar
color del icono
del colegio que
fue
seleccionado.
2.-No
mostrar/ocultar
los colegios
que no fueron
seleccionados
1.-Se deberá
cambiar el color del
icono del colegio
que fue
seleccionado (color
negro a color
amarillo).
2.-Se deberá
ocultar los colegios
que no fueron
seleccionados.
S
3
59
2.12.6 Plan de Proyecto
A partir de nuestra metodología de gestión del proyecto seleccionada se
realizara un plan de proyecto, el cual tendrá como objetivo poder entregar al big
boss tiempos estimados sobre la duración de cada fase del proyecto. Como toda
planificación esta se encuentra sujeta a modificaciones.
Según las distintas fases de un proyecto (Inicio, Planificación, Diseño,
Ejecución y Cierre y Control) nuestro proyecto se realizara de la siguiente manera
cada fase.
En primera instancia se deberá determinar las necesidades a satisfacer, es decir
con el cliente anotar las Historias de Usuario que el cliente desee acorde al
proyecto, para luego convertir esas HU en tareas y estimar un tiempo de
duración.(Etapa de Inicio).Luego para la etapa de Planificación se acordara
establecer un Product Backlog(en donde a cada HU se logra estimar y definir en
qué Sprint se realizara de acuerdo a las necesidades del cliente) y un Sprint
Backlog en donde en éste último se pondrán todas las tareas que se deberán
cumplir para la realización del Sprint, asignando dichas tareas a un responsable
del equipo de desarrollo. Dentro del proyecto cabe destacar que se realizaran
reuniones diarias que son aproximadamente de 10 minutos en donde el equipo
desarrollador comunicara al resto que es lo que falta, que se está haciendo y que
se hizo. En la etapa de diseño se logra realizar el diseño de las pruebas que se
van a realizar, ya sea de integración, unitarias, aceptación, carga, estrés etc.
además de diseñar todo lo a que a interfaz se refiere. En la etapa de ejecución se
realizaran todas las tareas que resultaron en el Sprint Backlog teniendo como
plazo máximo 2 a 3 semanas (dependiendo de la estimación realizada).En esta
etapa se deben ejecutar las pruebas unitarias o de integración. Finalmente se
logra realizar en la etapa de cierre o en Scrum llamado Sprint Review la liberación
de preproducción de la aplicación web, para que luego se realicen las pruebas de
aceptación. Una vez aprobadas dichas pruebas el equipo debe liberar la versión.
60
Para poder apreciar aproximadamente fechas sobre nuestro proyecto es que se
realizó esta Carta Gannt la que proporciona fechas estimativas durante cada fase
que se llevara a cabo en nuestro proyecto.
Nombre
Proyecto
Proyecto
Realizar Product Backlog
Sprint N°1
Sprint Backlog
Sprint Planning
Diseño Simple
Codificación
Pruebas
Validación Sprint N°1
Sprint Review
Sprint N°2
Sprint Backlog
Sprint Planning
Diseño Simple
Codificación
Pruebas
Validación Sprint N°2
Sprint Review
Sprint N°3
Sprint Backlog
Sprint Planning
Diseño Simple
Codificación
Pruebas
Validación Sprint N°3
Sprint Review
Sprint N°4
Sprint Backlog
Sprint Planning
Diseño Simple
Codificación
Pruebas
Validación Sprint N°4
Sprint Review
Liberación Producto
Sprint N°5
Sprint Backlog
Sprint Planning
Diseño Simple
Fecha Inicio Duración (Días) Fecha Termino
01/08/2014
136
31/05/2014
15/03/2015
77
31/05/2015
03/09/2014
1
04/09/2014
05/09/2014
25
30/09/2014
01/10/2014
2
03/10/2014
03/10/2014
5
08/10/2014
08/10/2014
3
11/10/2014
11/10/2014
10
21/10/2014
21/10/2014
5
26/10/2014
26/10/2014
3
29/10/2014
29/10/2014
2
31/10/2014
31/10/2014
25
25/11/2014
31/10/2014
2
02/11/2014
02/11/2014
5
07/11/2014
07/11/2014
3
10/11/2014
10/11/2014
10
20/11/2014
20/11/2014
5
25/11/2014
25/11/2014
3
28/11/2014
28/11/2014
2
30/11/2014
30/11/2014
25
25/12/2014
30/11/2014
2
02/12/2014
02/12/2014
5
07/12/2014
07/12/2014
3
10/12/2014
10/12/2014
10
20/12/2014
15/03/2015
5
20/03/2015
20/03/2015
3
23/03/2015
23/03/2015
2
25/03/2015
25/03/2015
25
19/04/2015
25/03/2015
2
27/03/2015
27/03/2015
5
01/04/2015
01/04/2015
3
04/04/2015
04/04/2015
10
14/04/2015
14/04/2015
5
19/04/2015
19/04/2015
3
22/04/2015
22/04/2015
2
24/04/2015
24/04/2015
1
25/04/2015
24/04/2015
25
19/05/2015
24/04/2015
2
26/04/2015
26/04/2015
5
01/05/2015
01/05/2015
3
04/05/2015
61
Codificación
Pruebas
Validación Sprint N°5
Sprint Review
Liberación Producto
Cierre Proyecto
04/05/2015
14/05/2015
19/05/2015
22/05/2015
24/05/2015
24/05/2015
10
5
3
2
1
7
14/05/2015
19/05/2015
22/05/2015
24/05/2015
25/05/2015
31/05/2015
62
2.11.7 Product Backlog
63
64
65
Figura 15:Product Backlog
66
El Product Backlog mostrado en la figura Nº15 es una lista de Historias de
Usuario, ordenadas según el valor de negocio que establece el Dueño del
Producto, y que trata de cubrir todas las necesidades necesarias a desarrollar. De
este documento se extraen las historias de usuarios que mayor beneficio entregue
al negocio, documentando luego las historias de usuario a realizar en el Sprint
Backlog. Las historias de usuario que entregan más valor a nuestro proyecto se
pueden apreciar debido al orden que se disponen. Este Product Backlog nos
entrega a nosotros una perspectiva clara de que es lo que se tiene que hacer,
teniendo claras las prioridades establecidas por el cliente, las estimaciones, en
que Sprint se realizara, de cierta forma es un documento que nos permite ser un
equipo auto disciplinado. Dicho Product Backlog representa la visión y las
expectativas que tiene el cliente respecto a los objetivos y entregas del producto,
además nos permite al equipo respetar las prioridades del cliente. Como se sabe
Scrum es una metodología ágil en donde las historias de usuario pueden ir
introduciendo cambios en el proyecto lo que permite que el usuario este siempre
en contacto con este documento que no resulta ser tan complejo respecto a otras
metodologías tradicionales.
De la figura Nº15 se puede apreciar en la primera columna un identificador
de la historia de usuario, único, que caracteriza a esa historia de usuario. En la
columna Nº2 aparece el nombre de historias de usuario, describiéndolas. En la
columna Nº6 se encuentra la importancia la cual se basó básicamente en la
técnica Mascow, la cual nos indica con una M si la HU debe incluirse, con una S si
se debería incluir, con una C si podría incluirse y con una W si no se incluye. En la
columna Nº 7 se realizó una estimación ocupando la técnica planning póker, en
donde a cada historia de usuario le asignamos un valor.
67
2.11.8
Gestión de Requerimientos
Para poder realizar una correcta gestión de requerimientos se hace a través
de encuestas, las cuales se realizan cada vez que se realiza el proceso de lean
startup, en donde lean startup aborda los lanzamientos de negocios y productos,
el que se basa en aprendizaje valido e iteraciones del lanzamiento del producto,
de tal manera de ganar una retroalimentación de los clientes. Debido a esto se
logran sacar métricas a través de las encuestas. Otra forma que nosotros hemos
estado realizando como se señaló anteriormente es a partir de la red social
Facebook donde tenemos nuestro Fan Page. En el vamos prácticamente
preguntando a la gente si es que tales avances han sido de su agrado.
Al realizar las encuestas y obtener las métricas correspondientes nos permite ver
de manera estadística los requerimientos que se deben abarcar o ir mejorando.
2.11.9
Gestión de Riesgos
En la Tabla N°19 se muestra el plan de mitigación y contingencia ante cada
riesgo existente, es importante destacar que no todos los riesgos pueden ser
eliminados no obstante, pueden desarrollarse planes de mitigación y contingencia
para reducir su impacto en el caso de que surjan. Cada riesgo tiene un
responsable el cual se hará cargo de cumplir dichos planes (Ver Tabla 19). El
análisis de los riesgos debe también identificar oportunidades no previsibles con el
fin de proporcionar beneficios adicionales. Nuestro proyecto posee los siguientes
riesgos, indicar además que los riesgos pueden ir apareciendo semana tras
semana, está sujeto a modificaciones. Además es se incluyen las tablas
valorización por impacto y probabilidad en donde cada una de ellas posee un
rango de números entre uno y cuatro con su respectiva descripción, lo que nos
permitirá entender de mejor manera las probabilidades e impacto que hay en cada
riesgo.
68
A medida que el proyecto avanza se van gatillando nuevos riesgos que se
verán reflejados en los riesgos de cada Sprint permitiendo tener un control sobre
los riesgos disparados o disminuidos por el Sprint. La forma de controlar los
riesgos es aplicar el plan de contingencia o mitigación en el caso de que el riesgo
sea mayor a 3 y 5 (nivel de riesgo). A medida que el proyecto avanza se van
gatillando nuevos riesgos que se verán reflejados en los riesgos de cada Sprint
permitiendo tener un control sobre los riesgos disparados o disminuidos por el
Sprint. La forma de controlar los riesgos es aplicar el plan de contingencia o
mitigación en el caso de que el riesgo sea mayor a 3 y 5 (nivel de riesgo)
respectivamente.
69
Tabla 13:Gestión Riesgos
70
2.11.10
Gestión de Configuración
Para la metodología XP y Scrum se utilizaran las herramientas
proporcionadas
por
la
Universidad
Andrés
Bello
Tortoise
SVN
(http://ing.escueladeinformatica.cl:8080/svn/PT_Labra_Figueroa). En donde dicha
herramienta nos facilita para tener una documentación con controles de versiones,
teniendo como línea base las primeras funcionalidades de la aplicación. Esta
herramienta entregada por la universidad es muy fácil de utilizar, además es una
herramienta en donde los profesores guías tienen acceso fácilmente. Esta
herramienta será utilizada específicamente por el equipo de desarrollo el cual
estará comprometido a subir sus distintas versiones del producto.
2.11.11
Control de versiones
A continuación se muestra en la tabla historial de versiones (figura Nº123)
todas las versiones que actualmente han sido realizadas y subidas al SVN
(herramienta de control de versiones), en la tabla se puede apreciar la fecha, la
versión una breve descripción y el autor. Cabe destacar que las versiones que se
encuentran en la siguiente tabla a su debido tiempo pasaron para un ambiente de
testing, pero sin embargo la última liberación fue liberada a cliente.
Fecha
Versión o
LineaBase
Descripción
Autor
26/09/2014
0.1
Creación del template.
Daniel Labra
30/09/2014
0.1.1
Implementación del mapa.
Daniel Labra
5/10/2014
0.1.2
Agregar colegios.
Fernando
Figueroa
71
10/10/2014
0.1.3
Implementar la ruta hacia los colegios.
Daniel Labra
10/10/2014
0.1.4
Base de datos conectada a la página.
Fernando
Figueroa
14/10/2014
0.1.5
Mostrar información de los colegios.
Daniel Labra
20/10/2014
0.2
Implementación Login Administración
Fernando
Figueroa
05/11/2014
0.2.2
Implementación búsqueda por criterio
25/11/2014
0.3
Implementación
5/12/2014
1.0
recomendador
Daniel Labra
“Me Fernando
Gusta”
Figueroa
Versión Final – Lista para revisión final.
Daniel Labra
Tabla 14: Control de Versiones
Un sistema de control de versiones provee un repositorio para el
almacenamiento de cambios en el código fuente. Es una locación para realizar
seguimiento de como el software cambia, cuando cambia, y quien lo cambia.
El éxito de un proyecto es altamente dependiente de cuan efectivo es el
sistema de control de versiones. El control de versiones se vuelve esencial para
las organizaciones de software de cualquier tamaño, debido a que un proyecto de
software produce un número de elementos durante su ejecución, incluyendo
documentos varios, programas, datos, y manuales. Todos estos elementos
pueden cambiarse fácilmente en cualquier momento durante el curso del proyecto.
Generalmente estos son los beneficios del control de versiones:
● El control de versiones mantiene un historial de cambios. Un historial se
mantiene por cada artefacto lo cual permite a los miembros del equipo
ayudar a determinar el porqué de las decisiones tomadas, qué ha sido
intentado en el pasado y quién hizo los cambios. También es importante
asegurar que todos los miembros del equipo pueden acceder siempre a la
72
versión actual, y también encontrar fácilmente o revisar versiones antiguas.
● El control de versiones es fundamental para equipos en coordinación y
mejora la comunicación entre miembros del equipo, el control de versiones
permite a cualquiera a leer y copiar los recursos del proyecto, pero solo
miembros del equipo autenticados o autorizados tienen permiso de
actualizarlos.
● Dado que se permite a más de un miembro del equipo a colaborar en un
solo artefacto al mismo tiempo, o de manera secuencial, el control de
versiones ayuda a asegurar que otro miembro del equipo no reemplace el
trabajo de un miembro del equipo, y ayuda a asegurar que el trabajo de
todos los miembros del equipo es consistente y compatible.
● Mejora la productividad del equipo de desarrollo y la calidad del trabajo
debido a que todos tienen visibilidad de todos los aspectos del proyecto.
● Con el control de versiones, es sencillo el manejo de la gestión de un
release del software y se incrementa la satisfacción del cliente.
Para nuestro proyecto utilizaremos la herramienta de SVN como nuestro
repositorio, el cual cuenta con:
● trunk, quiere decir el directorio debajo del cual se está desarrollando el
proyecto principal;
● branches, el cual es un directorio en donde se crean varias ramas de la
línea principal de desarrollo; y
● tags, en cual es un grupo de tomas en el tiempo del árbol que han sido
creadas, y quizá destruidas, pero nunca cambiadas.
La versión más reciente está ubicada debajo de /trunk/ la versión liberada está
ubicada debajo de /tags/.
Identificación de Versiones
● Cada elemento tiene un nombre de archivo, único en ese proyecto.
● Cada elemento tiene un identificador de versión asociado, el cual toma una
73
de dos formas:
- Un número entero, con la versión de línea base inicial comenzando en “1”,
e incrementando
- Un indicador decimal por ejemplo para el uso en documentación asociada
con un producto liberado.
● Cada elemento opcionalmente puede tener asociados a él: una descripción
del elemento, fecha de creación, razón por la cual se creó.
Herramienta Utilizada
● TortoiseSVN: Un cliente subversión gratis para el sistema operativo
Windows.
En la siguiente imagen se puede apreciar como nosotros subimos cada
parte y liberación de nuestro código a esta herramienta.
74
75
2.11.12
Control de cambios
Los cambios se realizaran si un requerimiento o funcionalidad produce un
impacto muy fuerte en el proyecto lo cual podría afectar su éxito, a lo cual se debe
estudiar el tipo de cambio, en un plazo máximo de 48hrs.
Para poder dejar una documentación más detallada del cambio solicitado
se pide llenar la siguiente plantilla:
1. Número se Solicitud de Cambio
2. Propósito del cambio
3. Estado de la Solicitud de Cambio
4. Información del Solicitante
5. Sistema(s) impactado(s)
6. Impacto a operaciones de sistema(s) existente(s)
7. Impacto a documentación asociada
8. Criticidad de la solicitud
9. Fecha de Necesidad
Nosotros utilizamos la herramienta Trac para poder llenar un control de lo
que se está realizando y de todo lo que se tiene que realizar. En caso, de que se
realice un cambio este estará registrado en los tickets lo cual permite una mejor
organización para realizar las tareas.
76
Este es el proceso formal al momento de realizar un cambio:
Para ver nuestros tickets pueden ingresar a:
-
http://han.ing.unab.cl:8080/trac/pt_labra_figueroa
77
2.11.13
Ambiente de Desarrollo
Para el desarrollo del sistema se utilizarán las siguientes herramientas:
Sublime text 2 es una herramienta que nos permitirá ir editando el código
establecido en html5.
Se utilizaran los siguientes dos notebooks y Servidor:
1. Notebook HP, procesador Intel Core i5 con 6GB de RAM con sistema
operativo Windows 7.
2. Notebook Samsung, procesador Intel Core i7 con 8 GB de RAM y Sistema
operativo Windows 7.
3. Servidor de base de datos MySQL
Además como software se utilizara:
1. Text Sublime 3 v2.2
2. Microsoft Excel 2013
Dentro del lenguaje de programación que se utilizara:
1. Php
2. Sql
Control de versiones
1. Svn
2. Trac
78
2.11.14
Ambiente de Pruebas
Para el ambiente de pruebas del sistema implica probar el sistema global
en donde nos permita establecer si se cumplen los requisitos impuestos con
anterioridad. Antes de realizar dichas pruebas se deben cumplir a cabalidad las
pruebas unitarias y las pruebas de integración. El ambiente para la realización de
dichas pruebas es el siguiente:
Servidor
•
Apache + PHP + Base de datos MySQL
•
Sistema Operativo Windows
Servidor de pruebas externo
•
Sistema operativo: Windows
•
Dominio servidor de pruebas externo: http://han.ing.unab.cl/faceschool/
•
Servidor de base de datos MySQL: http://han.ing.unab.cl/phpmyadmin
Sesiones simultáneas de pruebas
•
Pruebas de carga: 50 peticiones
simultáneas.
Aplicacion
a
utilizar
JMeter.
79
Software para pruebas
•
Apache JMETER
PC
•
Equipo cliente.
2.11.15
Ambiente de Producción
Nuestro ambiente de producción es el mismo ambiente de desarrollo por lo
cual se ocuparan los mismos equipos y tecnología.
2.11.16
Plan de Pruebas
El propósito de la realización del plan de pruebas, es la especificación del
enfoque, alcance y recursos requeridos para la realización de las pruebas. En el
siguiente plan de pruebas se describirán las dos actividades fundamentales para
la realización de las pruebas correspondientes a la prueba de componentes y la
realización de las pruebas de sistema.
Los objetivos de la etapa de pruebas son los
siguientes:
● La demostración al Product Owner que el software satisface las HU, lo
que significa la realización de las pruebas en relación a los
requerimientos definidos por el cliente en conformidad a la versión
definida para ser liberada.
● Descubrir defectos en el software en que el comportamiento de éste es
incorrecto, no deseable o no cumple con su especificación.
80
Pruebas Desarrollador
Estrategias de pruebas
PRUEBA
RESPONSABLE
Pruebas de integridad de datos y BD
F.Figueroa
Pruebas Unitarias
D.Labra
Pruebas de la interfaz de usuario (IU)
F.Figueroa
D.Labra
Pruebas de Desempeño
F.Figueroa
Pruebas de Cargas
D.Labra
Pruebas de Volumen
F.Figueroa
Pruebas de Integración
Tabla 15: Plan de Pruebas
A continuación se detalla cada tipo de pruebas con su respectivo objetivo,
técnica a utilizar y el criterio a cumplir para que dicha prueba sea aprobada sin
ningún inconveniente.
81
Pruebas de integridad de datos y BD
Objetivos
Técnica a utilizar
Asegurar que los métodos
de acceso y los procesos
funcionen de manera
correcta.
Invocar los métodos de
acceso a la BD,
intentando ingresar con
datos validos e inválidos.
Criterio a cumplir
Todos los métodos
funcionan de manera
correcta. Mensaje de
alerta correspondiente.
Tabla 16: Pruebas de Integridad BD
Pruebas de Sistema
Objetivos
Asegurar el correcto
funcionamiento del
sistema.
Técnica a utilizar
Criterio a cumplir
Invocar cada
funcionalidad ingresando
datos validos e inválidos.
Mensaje de alerta
correspondiente al error o
alerta producido.
Tabla 17: Pruebas de Sistema
Pruebas de Rendimiento
Objetivos
Asegurar el correcto
funcionamiento del
sistema.
Técnica a utilizar
Invocar cada
funcionalidad ingresando
datos validos e inválidos.
Criterio a cumplir
El rendimiento del
sistema deberá ser
medible y apropiado a la
funcionalidad probada.
Tabla 18: Pruebas de Rendimiento
82
Pruebas de la interfaz de usuario (IU)
Objetivos
Asegurar el correcto
funcionamiento de la
funcionalidad según la
interfaz.
Técnica a utilizar
Probar cada funcionalidad
acorde a lo que aparezca
como funcionalidad.
Criterio a cumplir
Que la funcionalidad
cumpla y realice la
función acordada.
Tabla 19: Pruebas de Interfaz
Pruebas de carga
Objetivos
Verificar el tiempo de
respuesta del sistema al
realizar alguna
funcionalidad.
Técnica a utilizar
La herramienta a utilizar
será Jmeter.
Criterio a cumplir
Cumplir dentro de un
tiempo aceptable la
funcionalidad solicitada.
Tabla 20: Pruebas de Carga
83
Capítulo IV
2.12 Resultado y Discusión
2.12.1 Sprint Nº1
2.12.2 Planning Meeting
Nuestro Planning Meeting esta dado como una reunión que se realiza entre
el equipo de desarrollo y nuestro Product Owner (PO) teniendo una duración de
máximo 3 horas. El objetivo es que el Equipo seleccione aquellos elementos del
Product Backlog que cree que puede comprometerse a transformar en un
incremento de funcionalidad potencialmente entregable que finalmente se
demostrará esta funcionalidad al PO en el Sprint review meeting al final del Sprint.
Luego nuestro PO está atento a nuestras preguntas que podamos realizar sobre el
Sprint Backlog que se acordó. Finalmente el resultado de esta reunión es realizar
el Sprint Backlog tareas que tiene como finalidad estimar las tareas a realizar
durante el sprint y asignaciones a éstas para así dar comienzo al trabajo del
Equipo para desarrollar la funcionalidad. En nuestro caso se presenta a
continuación el Sprint Backlog (2.12.3) acordado con las historias de usuario
correspondientes que se realizaran, para finalmente tener como resultado nuestro
Sprint Backlog Tareas (2.12.6).
84
2.12.3 Sprint Backlog
Figura 16: Sprint Backlog
En la figura Nº16 se puede apreciar nuestro sprint backlog. Éste tiene como propósito establecer que HU se
atacaran en el sprint. En nuestro caso en el sprint Nº1 se atacaran las HU Nº7 y Nº8.Estas HU se les realizo un análisis
en el Product Backlog por lo que ahora se necesita crear un EDT o estructura de desglose de tareas, en donde se define
a grandes rasgos que se hará en dicho sprint. Se seleccionaron estas dos HU debido a que según el PO estas, resultan
tener mayor valor hacia el negocio del cliente, además se quiere minimizar los riesgos que conlleva a implementar dichas
HU.
85
2.12.4 EDT
El EDT es un gráfico en el que los elementos de trabajo críticos, actividades
y tareas de un proyecto, se representan para retratar sus relaciones entre sí y con
el proyecto en su conjunto. La finalidad de construir un EDT resulta ser que éste
puede ayudar a un gerente de proyecto a predecir los resultados basados en
diversos escenarios, lo que contribuye a optimizar la toma de decisiones en todo lo
relativo a procedimientos y cambios.
En la figura Nº17 se puede apreciar nuestro EDT, en donde se define los
objetivos clave y se identifica a grandes rasgos las tareas necesarias para
alcanzar esas metas. La finalidad de cumplir con este EDT que si bien no es un
plan a seguir nos entrega al equipo una ayuda para ganar precisión a la hora de
definir y organizar el alcance del proyecto. Según las faces previamente descritas
que tenía la metodología de desarrollo es que se realizó el EDT.
Figura Nº22 EDT
Figura 17: EDT
El Sprint Backlog tareas es un listado de todas las tareas que se van a
realizar para cumplir con la historias de usuario seleccionada. La figura N°28 tiene
dicho objetivo, cada tarea tiene un responsable que está asociada a una actividad
86
específica, además de indicarnos los días que se trabajan en el proyecto, se
identifican las horas que faltan para terminar dicha tarea. Para cada iteración se
debe realizar un Sprint Backlog, los cuales tendrán diferentes tareas.
La figura Nº16 representa nuestro sprint backlog con tareas. Esta plantilla
nos fue de gran utilidad ya que nos va entregando información necesaria tanto
para el equipo desarrollador y a nuestro big boss, lo que nos permitió a nosotros
como equipo de desarrollo planificarnos día a día sobre nuestro proyecto. En la
imagen se puede apreciar que se hicieron un total de 128 horas repartidas en las
22 tareas para ambas HU. Como se puede apreciar cada tarea tenía un
responsable que se fue asignado el cual era el encargado de realizar dicha tarea.
Si bien estas tareas se iniciaban en una determinada estimación de horas, era
posible que con el pesar del tiempo las horas trabajadas o resultantes no
reflejaban las horas trabajadas, ya que se dio el caso en donde para terminar una
tarea quedaban 4 hrs, pero finalmente quedaban 5 hrs debido a que no se avanzó
y además se presentaron problemas.
2.12.5 Criterio de Aceptación
Las pruebas de aceptación son básicamente pruebas funcionales, sobre el
sistema completo, y buscan una cobertura de la especificación de requisitos y
del manual del usuario. Estas pruebas no se realizan durante el desarrollo, pues
sería impresentable al cliente; sino que se realizan sobre el producto terminado e
integrado o pudiera ser una versión del producto o una iteración funcionando.
Cada prueba de aceptación consta de una sucesión de pasos y decisiones que se
siguen para realizar una determinada actividad o tarea. Estas pruebas que se
realizan con el cliente tienen como función probar con el cliente en un escenario
del sistema normal el comportamiento de lo que él se espera, demostrando al
cliente el cumplimiento de un requisito o en nuestro caso de una HU.
A continuación en las tablas Nº 21 y Nº22 se pueden apreciar los criterios
de aceptación que el Product Owner realizo para nuestro proyecto. Como bien se
87
señaló antes están compuestas de un ID único, Nombre, una pre condición que se
debe efectuar antes, una condición para que se realice la acción, los pasos que se
deben realizar y los resultados esperados.
Tabla 21: Prueba Aceptación Ruta
88
Tabla 22:
Prueba Aceptación Información
89
2.12.6 Sprint Backlog Tareas
Figura 18:Sprint Backlog Tareas
90
2.12.7 Diseño Sprint Nº1
A continuación se muestran las tarjetas CRC que se implementaron en este
Sprint Nº1.Estas tarjetas se componen del nombre de la clase, responsabilidades
y colaboradores. La finalidad de estas es mostrar igual que en un diagrama de
clases ver sus atributos y métodos que actúan en cada clase. Estas tarjetas que
son utilizadas en la metodología desarrollo XP, representa de distinta manera lo
que es el Diagrama de Clases.
La tabla Nº23 corresponde a la clase Ruta, la que tiene como
colaboradores Interfaz, Colegio, Mapa y Servidor.
Tarjeta CRC
Faceschool
Datos de la clase
Nombre de la clase: Ruta
Responsabilidades
Colaboradores
traveltoAddress()
Mapa: index.php
directionsService.route(request.getRuta)
Tabla 23:
CRC Ruta Sprint Nº1
91
La tabla Nº24 corresponde a la clase información, la que tiene como
colaboradores Interfaz, Colegio y Servidor.
Tarjeta CRC
Faceschool
Datos de la clase
Nombre de la clase: Información
Responsabilidades
Colaboradores
Base_url(colegio/show)
Mapa: index.php
Public function Show()
Colegio: show.php
Get_colegio(colegios_id)
Controllers: colegio
Return $query->Row()
Models: colegio_model.php
View(colegio/show, $dato)
Tabla 24: CRC Información Sprint Nº1
A continuación se pueden apreciar el diseño implementado en nuestro Sprint
Nº1.Los diagramas de secuencias presentados a continuación (Figura Nº 25 y
Figura Nº26) representan la secuencia sobre la funcionalidad realizadas “Ruta” e
“información” respectivamente.
92
En esta figura (figura Nº19) se puede apreciar la funcionalidad de ver ruta.
El usuario ingresa a nuestra página web en donde de manera automática se
cargan los colegios. El usuario deberá seleccionar un colegio para que finalmente
el servidor devuelva la información a la interfaz, en donde aparecerá en un mapa
la ruta más cercana hacia el colegio seleccionado desde su ubicación.
Figura 19:
Diagrama Secuencia Ruta
93
En la figura Nº20 se puede apreciar la funcionalidad ver información del
colegio. Esta funcionalidad se inicia con el usuario en donde deberá seleccionar el
colegio para que finalmente el servidor devuelva la información que se tenga
respecto a este colegio, a la interfaz.
Figura 20: Diagrama Secuencia Información
94
A continuación se puede apreciar nuestro diagrama de despliegue
correspondiente al Sprint Nº1.
Figura 21: Diagrama de Despliegue Sprint Nº1
95
En la figura a continuación se puede apreciar nuestro diagrama de
componentes. El cual se conforma principalmente por el Landing, el Mapa y el
Colegio.
Figura 22: Diagrama de Componentes Sprint Nº1
96
La siguiente figura muestra el diseño de nuestra base de datos conformado
para el sprint Nº1, con sus respectivas clases, claves primarias, claves foráneas y
conexiones.
Figura 23: Diseño de BD Sprint Nº1
97
2.12.8 Evidencia Interfaces
Las siguientes imágenes hacen relación a la evidencia de las interfaces
creadas para este Sprint Nº1.La siguiente interfaz (Imagen Nº1 y Nº2)
corresponden a la ruta desde mi ubicación hacia el colegio seleccionado, al
apretar el botón “como llegar” se traza la ruta más cercana desde mi ubicación
hacia el colegio.
Imagen Nº1
Imagen Nº2
98
Las siguientes imágenes (Imagen Nº3) corresponden a luego de seleccionar el
botón “ver información” respecto al colegio seleccionado.
Imagen Nº3
99
Imagen Nº3
100
2.12.9 Pruebas Unitarias
Las pruebas unitarias se conforman principalmente de un identificador de la
prueba, identificador de la HU que se probó, una descripción de la prueba a
realizar, y los distintos escenarios en los que será probada, además tendrá un
resultado esperado en donde si cumple dicho resultado la prueba fue realizada
con éxito.
Las figuras Nº24 y Nº25 son el diseño de pruebas unitarias con sus
respectivos resultados que se realizó para este sprint. Dichas pruebas se
realizaron bajo la herramienta PHP Unit, la cual nos facilitó el trabajo para realizar
las pruebas diseñadas. La finalidad de realizar estas pruebas unitarias es
comprobar el correcto funcionamiento de un módulo de código, comprobando
finalmente si el modulo probado presenta errores. Estas pruebas aisladas
proporcionan ciertas ventajas como lo son la simplificación de las pruebas de
integración, dado que permite realizar estas pruebas con un grado alto de
seguridad de que el código ya aisladamente está funcionando de manera correcta.
De igual forma al detectar un error, resultaría más fácil encontrarlo en este tipo de
pruebas que en las pruebas de integración.
101
Figura 24:
Prueba Unitaria Ruta
102
La prueba realizada al módulo Mapa (figura Nº24) fue realizada con un
éxito total, ya que de las 2 pruebas realizadas al módulo tuvieron un resultado
acorde a lo esperado. De igual manera las pruebas realizadas al módulo
Información fueron un éxito debido a que se obtuvo el resultado esperado.
Figura 25:
Pruebas Unitarias Información
103
A continuación se muestra evidencia creada en el trac a partir de la realización de las pruebas unitarias correspondiente
al Sprint Nº1.
Figura 26:
TRAC Pruebas
104
2.12.10
Evidencia de seguimiento y control de cambios
En la figura a continuación se puede apreciar el uso del Trac. La finalidad de mostrar esto es que nos permite
ingresar tickets y hacerle un seguimiento a cada uno de ellos. La idea es ir ingresando tickets a medidas que vaya siendo
necesario ,permitiendo poner una breve descripción del ticket, el tipo, la fecha creada y la fecha en que fue realizado,
además de establecer un responsable y si finalmente el ticket fue resuelto o se encuentra con alguna observación.
Figura 27:
TRAC
105
2.12.11Liberación del Producto
Para este Sprint Nº1 no existe liberación del Producto.
2.12.12Evidencia Línea base
A continuación se puede apreciar que la línea base correspondiente a la versión
0.1 se encuentra en SVN.
Figura 28:
SVN
106
2.12.13
Burndown
A continuación se puede apreciar el grafico Burn Down (Gráfico Nº2).En
este grafico se puede apreciar como el equipo de desarrollo se comportó respecto
a la estimación realizada previamente. A partir de la estimación (línea azul) y el
trabajo restante (línea roja) se puede ver como el trabajo realizado se fue
adecuando cada vez más hacia la línea azul lo que nos indica que se fue
trabajando acordado al plan o a la estimación de las tareas. Este grafico nos
permite analizar por ejemplo si al momento de activarse un riesgo si se actuó
inmediatamente o no. En nuestro caso se puede apreciar que se demoró un día en
actuar respecto a un riesgo disparado como se puede ver en el gráfico, pero
finalmente no influyo en los tiempos de nuestro proyecto.
Gráfico Nº2 BurnDown
107
2.12.14 Evolución de los Riesgos
Es de suma importancia a medida que se va realizando el sprint, hacerle un
seguimiento a los respectivos riesgos que hay en el proyecto ya sea antes,
durante y después del sprint. La finalidad de hacerles un seguimiento a los riegos
identificados es saber cuándo éstos se están disparando para actuar rápidamente
con un plan de mitigación o contingencia cuando sea necesario .Además es
necesario saber cuáles ya dejan de ser riesgos potentes para el sprint. Es por
eso que como se muestra en el gráfico Nº3 se muestran los riegos que fueron
identificados principalmente dentro del sprint o bien que fueron identificados antes
del sprint.
Gráfico Nº3 Riesgos
108
Como se puede apreciar en el gráfico Nº3 se muestra el nombre del riesgo,
el id del riesgo y la probabilidad de los riesgo semana a semana, en donde el valor
1 se expresa como una baja probabilidad y el valor 5 se expresa como una alta
probabilidad. De igual manera se puede expresar en forma de grafico dichos
riesgos presentados en la tabla en donde se pueden apreciar cómo van
evolucionando semana a semana. Esto nos permite a nosotros como equipo tener
primero conocimiento de los riegos pero sobre todo un seguimiento claro para
saber en qué momento actuar respecto a un riesgo.
2.12.15 Post Mortem Sprint Nº1
Dentro del post mortem podemos señalar que para nosotros fue un gran
desafío empezar a trabajar en herramientas que no teníamos muchos
conocimientos pero sin lugar a dudas es un desafío que estamos dispuestos a
seguir construyendo esta página web. El haber finalizado nuestro primer sprint
dentro de los plazos establecidos nos deja sin lugar a dudas una vara muy alta
para el segundo sprint. Debemos mencionar que siempre hay cosas por mejorar y
en este caso creemos que no realizamos una buena estimación acorde a las
tareas asociadas a las HU, ya que muchas veces debimos trabajar más de lo que
habíamos estimado para realizar y cumplir dicha tarea. Además debemos mejorar
lo que son en la realización de pruebas ya que si bien realizamos pruebas de
aceptación y unitarias, no quedamos conforme con la realización de estas, debido
a que se pudieron realizar más y por ende probar más casos extremos. De igual
forma nos sentimos capaces de llevar este proyecto a cabo ya que poco a poco
vamos conociendo las herramientas necesarias para sacar el proyecto adelante lo
que nos tiene muy satisfecho.
109
2.12.13 Sprint Nº2
2.12.14 Planning Metting
Nuestro Planning Meeting esta dado como una reunión que se realiza entre
el equipo de desarrollo y nuestro Product Owner (PO) teniendo una duración de
máximo 3 horas. Está reunión se realiza en la Universidad Andrés Bello a un
horario acordado. El objetivo es que el Equipo seleccione aquellos elementos del
Product Backlog que cree que puede comprometerse a transformar en un
incremento de funcionalidad potencialmente entregable que finalmente se
demostrará esta funcionalidad al PO en el Sprint review meeting al final del Sprint.
Luego nuestro PO está atento a nuestras preguntas que podamos realizar sobre el
Sprint Backlog que se acordó. Finalmente el resultado de esta reunión es realizar
el Sprint Backlog tareas que tiene como finalidad estimar las tareas a realizar
durante el sprint y asignaciones a éstas para así dar comienzo al trabajo del
Equipo para desarrollar la funcionalidad. En nuestro caso se presenta a
continuación el Sprint Backlog (2.12.15) acordado con las historias de usuario
correspondientes que se realizaran, para finalmente tener como resultado nuestro
Sprint Backlog Tareas (2.12.17).
110
2.12.15 Sprint Backlog
En la figura Nº29 se puede apreciar nuestro sprint backlog. Éste tiene como propósito establecer que HU se
atacaran en el sprint. En nuestro caso en el Sprint Nº2 se atacaran las HU Nº2 y Nº9. Se seleccionaron estas dos HU
debido a que según el PO estas, resultan tener mayor valor hacia el negocio del cliente, además se quiere minimizar los
riesgos que conlleva a implementar dichas HU.Todo Sprint debe tener una meta y un objetivo el cual se puede apreciar
detalladamente en la columna Nº10 y Nº11 respectivamente.
Figura 29: Sprint Backlog Nº2
111
2.12.16 Criterio de Aceptación
A continuación se muestran las pruebas de aceptación (tabla Nº37 y Nº38)
con las que se atacó cada HU. Están compuestas básicamente con un Nombre,
una Pre condición, una condición los pasos a realizar y los resultados esperados.
Tabla 25: Criterio de Aceptación Búsqueda
112
Tabla 26: Criterio de Aceptación Login
113
2.12.17 Sprint Backlog Táreas
En la siguiente imagen se detallan las tareas que se debieron realizar para cumplir con el Sprint Nº2, se
completaron un total de 23 tareas con un total de 123 horas. Recordar que este Sprint se inició el día 20 de Octubre del
2014 finalizando el día 4 de Noviembre del 2014.A partir de la imagen se visualiza como el equipo fue trabajando día a
día sobre las tareas a realizar en las cuales se nota una hora estimada por cada tarea y luego las horas restantes que le
queda a esa tarea.
Figura 30: Sprint Backlog Tareas
114
2.12.18 Diseño Sprint Nº2
A continuación se detallan las tarjetas CRC comprendidas en este Sprint.
Se podrá apreciar el nombre de la clase, las responsabilidades y colaboradores.
Faceschool
Datos de la clase
Nombre de la clase: Login Administrador
Responsabilidades
Colaboradores
public function login()
Administracion: Login
public function login_action()
Controllers: Administracion
public function logout()
Models: colegio_model.php
private function autorizar()
function get_administracion_login()
Tabla 27:CRC Login
Tarjeta CRC
Faceschool
Datos de la clase
Nombre de la clase: Filtro
Responsabilidades
Colaboradores
Base_url(mapa/filtro)
Mapa:index.php
public function filtro()
Controllers: mapa
function filtro($comuna, $dependencia,
$religion, $idioma)
Mapa:filtro
Rerturn ($query)
Models: colegios_models
Tabla 28:CRC Búsqueda
115
En la figura a continuación se presenta el diagrama de secuencia
correspondiente a la HU Nº2, con sus respectiva secuencia que tanto como el
usuario y el sistema debe realizar.
Figura 31:
Diagrama Secuencia Sprint Nº2
116
El diagrama de secuencia a continuación corresponde a la HUº9 llamada
Búsqueda. Esta HU tiene como fin poder realizar una búsqueda de colegios a
partir de los filtros que el usuario debe seleccionar.
Figura 32:
Diagrama Secuencia Sprint Nº2
117
Otro de los diagramas a mostrar es el llamado diagrama de despliegue en
donde no tiene mayores cambios respecto al Sprint Nº1.
Figura 33:
Diagrama Despliegue Sprint Nº2
118
El diagrama que se muestra a continuación representa el diagrama de
componentes de nuestro Sprint Nº2, al cual se le agrego el componente
Administración con sus respectivos sub componentes Login.php, Inicio.php y
modificar_show.php.
Figura 34:
Diagrama Componentes Sprint Nº2
119
A continuación se nuestra nuestro diagrama de la base de datos
implementado, si bien no cambio mucho respecto al Sprint Nº1 la tabla que fue
incluida es la tabla de Admin, la cual nos permitirá almacenar el usuario y
contraseña de cada administrador.
Figura 35:
Diagrama de Clases Sprint Nº2
120
2.12.19
Las
Evidencia Interfaces
siguientes
imágenes
correspondiente
corresponden
a
al
las
interfaces
Sprint
implementadas
Nº2.
En la Imagen Nº4 se puede apreciar que se puede realizar una búsqueda según
los filtros y automáticamente en el mapa se actualizarán los colegios
correspondientes a los filtros seleccionados. Para este caso se seleccionó una
comuna Viña del Mar con un tipo de dependencia Particular Pagado, religión
católica e idioma Ingles, lo cual el sistema arrojo cuatro colegios que cumplían con
las características buscadas.
Imagen Nº4
121
En la imagen Nº5 se logra ver el login que se realizó para poder acceder a realizar
mantenciones ya sea agregar, modificar o eliminar colegios. Cada administrador
posee un usuario y contraseña el cual ingresándolo de manera correcta podrá
acceder a la siguiente ventana, en cambio sí se ingresó algún dato incorrecto el
sistema arroja un mensaje con el siguiente error: “Usuario y/o contraseña invalida”.
Imagen Nº5
122
En la imagen a continuación se puede apreciar el “menú” para agregar,
modificar o eliminar un colegio. Estas acciones las puede realizar solamente un
administrador.
Imagen Nº6
2.12.20
Pruebas Unitarias
Las tablas Nº29 y Nº30 son el diseño de pruebas unitarias con sus
respectivos resultados que se realizó para este sprint. Dichas pruebas se
realizaron bajo la herramienta PHP Unit, la cual nos facilitó el trabajo para realizar
las pruebas diseñadas. La finalidad de realizar estas pruebas unitarias es
comprobar el correcto funcionamiento de un módulo de código, comprobando
finalmente si el modulo probado presenta errores. Estas pruebas aisladas
proporcionan ciertas ventajas como lo son la simplificación de las pruebas de
integración, dado que permite realizar estas pruebas con un grado alto de
123
seguridad de que el código ya aisladamente está funcionando de manera correcta.
De igual forma al detectar un error, resultaría más fácil encontrarlo en este tipo de
pruebas que en las pruebas de integración.
Tabla 29: Diseño de Prueba Búsqueda
124
Tabla 30: Diseño de Prueba Login
125
Como se puede ver en la siguiente figura Nº36 se puede apreciar que se creó un “ticket” sobre la realización de las
pruebas unitarias para el Sprint Nº2.
Figura 36:
TRAC Pruebas
126
2.12.21
Liberación del Producto
En este Sprint Nº2 no hubo liberación del producto.
2.12.22
Evidencia Línea base
Como se puede apreciar en la siguiente figura la línea base correspondiente a la
versión 0.2 se encuentra en SVN.
Figura 37: SVN
127
2.12.23
Burndown
Como se puede apreciar en el grafico Burndown del Sprint Nº2, se puede
notar claramente como fue desarrollando el equipo de trabajo este Sprint Nº2
respecto a la estimación realizada en un principio. Además se visualiza que
hubieron lapsos en donde el equipo se encontró trabajando bajo la estimación
realizada, lo que habla de un equipo comprometido y capaz de realizar las tareas
propuestas de forma eficaz.
Gráfico Nº5 Burndown Sprint Nº2
128
2.12.24
Evolución de los Riesgos
Es de suma importancia realizar un exhaustivo seguimiento a los riesgos de
este Sprint Nº2, es que por eso se realiza un seguimiento en donde se pueden
apreciar los riesgos que han incrementado dentro de éste Sprint. Es por eso que
se puede apreciar como por ejemplo el riesgo numero 13 fue disminuyendo acorde
se realizaba este Sprint.
Figura 38:
Riesgos Sprint Nº2
129
2.12.25 Post Mortem
Luego de realizar este segundo Sprint y con ya claro conocimiento del
proyecto el haber manejado gran parte del Sprint Nº1 con gran eficacia es que
este Sprint Nº2 fue una gran instancia para seguir aprendiendo sobre las
herramientas que estamos utilizando. Sin lugar a dudas la velocidad del equipo fue
mejor pero lo que no nos dejó conforme nuevamente fue las pruebas que
ejecutamos a éste Sprint. Sin embargo tenemos muy en claro que en el Sprint Nº3
mejoraremos realizando las pruebas acordadas anteriormente.
130
2.12.26
Sprint Nº3
2.12.27
Sprint Planning Meeting
Nuestro Planning Meeting esta dado como una reunión que se realiza entre
el equipo de desarrollo y nuestro Product Owner (PO) teniendo una duración de
máximo 3 horas. Está reunión se realiza en la Universidad Andrés Bello a un
horario acordado. El objetivo es que el Equipo seleccione aquellos elementos del
Product Backlog que cree que puede comprometerse a transformar en un
incremento de funcionalidad potencialmente entregable que finalmente se
demostrará esta funcionalidad al PO en el Sprint review meeting al final del Sprint.
Luego nuestro PO está atento a nuestras preguntas que podamos realizar sobre el
Sprint Backlog que se acordó. Finalmente el resultado de esta reunión es realizar
el Sprint Backlog tareas que tiene como finalidad estimar las tareas a realizar
durante el sprint y asignaciones a éstas para así dar comienzo al trabajo del
Equipo para desarrollar la funcionalidad. En nuestro caso se presenta a
continuación el Sprint Backlog (2.12.28) acordado con las historias de usuario
correspondientes que se realizaran, para finalmente tener como resultado nuestro
Sprint Backlog Tareas (2.12.30).
131
2.12.28 Sprint Backlog
En la figura a continuación se puede apreciar nuestro Sprint Backlog. Éste tiene como propósito establecer que HU
se atacaran en el sprint. En nuestro caso en el Sprint Nº3 se atacaran las HU Nº10. Se seleccionaron esta HU debido a
que según el PO estas, resultan tener mayor valor hacia el negocio del cliente, además se quiere minimizar los riesgos
que conlleva a implementar dichas HU. Todo Sprint debe tener una meta y un objetivo el cual se puede apreciar
detalladamente en la columna Nº10 y Nº11 respectivamente.
Tabla 31:Sprint Backlog Sprint Nº3
132
2.12.29
Criterio de Aceptación
Tabla 32: Criterio Aceptación Sprint Nº3
133
2.12.30 Sprint Backlog Tareas
En la siguiente imagen se detallan las tareas que se debieron realizar para cumplir con el Sprint Nº3, se
completaron un total de 19 tareas con un total de 72 horas. Recordar que este Sprint se inició el día 7 de Noviembre del
2014 finalizando el día 24 de Noviembre del 2014.A partir de la imagen se visualiza como el equipo fue trabajando día a
día sobre las tareas a realizar en las cuales se nota una hora estimada por cada tarea y luego las horas restantes que le
queda a esa tarea. Además mencionar que se debió realizar una tarea extra como observación del PO respecto a la HU
Nº1 la cual no presentaba mayor complejidad.
Figura 39:
Sprint Backlog Tareas Sprint Nº3
134
2.12.31 Diseño Sprint Nº3
A continuación se detalla la tarjeta CRC sobre la historia de usuario Nº10
Recomendador.
Las
tarjetas
Clase
Responsabilidades
Colaboradores
se
componen justamente de estos 3 datos. En donde para la clase se detallan las
responsabilidades y colaboradores.
Faceschool
Datos de la clase
Nombre de la clase: me_gusta
Responsabilidades
Colaboradores
SeleccionarFiltros
Mapa: Recomendador
Get_megusta
Models: colegio_model
$query->get_megusta
Config: database
$recomendador
Tabla 33:CRC Recomendador
135
En la figura Nº40 se puede apreciar el diagrama de secuencia
correspondiente a la HU Nº10.
Figura 40:
Diagrama Secuencia Sprint Nº3
136
Figura 41:
Diagrama de Despliegue Sprint Nº3
137
Figura 42:Diagrama de Componentes Sprint Nº3
138
La figura que se muestra a continuación se puede apreciar el diagrama de
de la base de datos correspondiente al Sprint Nº3, la tabla que se agrego es Me
Gusta la cual básicamente almacena el ip del usuario que puso me gusta en un
colegio y el id de aquel colegio. Con esos datos podemos evitar que la misma
persona ponga más de una vez en el mismo colegio.
Figura 43:
Diagrama de Clases Sprint Nº3
139
2.12.32
Evidencia Interfaces
Como se puede apreciar a continuación se muestran las interfaces
implementadas para el Sprint Nº3 (Imagen Nº6 y Nº7).En éste Sprint estaba
complementado realizar el recomendador de colegios el cual a partir de la ventana
de la información del colegio el usuario tiene la opción de realizar un “Me Gusta”,
además puede comentar a través de Facebook o recomendar este colegio. Dicha
información se muestra en la Imagen Nº7 la cual como se puede visualizar
muestra según la selección de filtros los colegios que tengan mayor cantidad de
“Me Gusta”. Luego en la parte inferior se puede apreciar que personas han
recomendado los colegios además de saber cuál.
140
Imagen Nº6
Imagen Nº7
141
2.12.31
Pruebas Unitarias
Tabla 34:Pruebas Unitarias Recomendador Sprint Nº3
142
2.12.32
Pruebas Ejecutadas
A continuación se realizaran las
pruebas de carga las cuales fueron
realizadas con la herramienta Jmeter. Se realizaran distintas pruebas para ver la
carga que soporta el sistema.
Tipo de Prueba
Carga
Herramienta utilizada
Jmeter
Nº de usuarios:
10
Tiempo en hacer las peticiones:
1
Resultado obtenido:
El servidor es capaz de aguantar 10
usuarios realizando peticiones cada 1
seg.
Evidencia:
143
Tipo de Prueba
Carga
Herramienta utilizada
Jmeter
Nº de usuarios:
25
Tiempo en hacer las peticiones:
1
Resultado obtenido:
El servidor no es capaz de soportar a
25 usuarios realizando peticiones
cada 1 seg.
Evidencia:
144
145
En la siguiente figura Nº44 se puede ver como se realizaron los “tickets” para lo que es la realización de pruebas tanto
unitarias como de carga.
Figura 44:
TRAC Pruebas
146
2.12.33 Liberación del Producto
Fase: Inicio
Iteración: Sprint Nº1, Sprint Nº2 y Sprint Nº3
Fecha: 5-12-2014
Versión: 1.0
Responsables: Daniel Labra, Fernando Figueroa
En esta primera iteración se tiene como propósito liberar el primer sprint de
Faceschool, el cual, ataca las siguientes historias de usuario:
-
Ver la ruta hacia el colegio
Que aparezca información sobre los colegios
Que se visualicen los colegios en el mapa
Realizar una búsqueda según criterios establecidos.
Que el sistema recomiende basado en la cantidad de Me Gusta de los
colegios según los criterios.
Objetivos
El propósito de realizar esta liberación es que se pueda poner a disposición de
los usuarios nuestro sitio web para que así puedan probar nuestro producto, a su
vez poder obtener una versión más estable y así eliminar ciertos riesgos de
nuestro proyecto.
Criterios a cumplir
Para la liberación se deberá pasar el 80% de los casos de prueba, con el fin
de lograr una liberación exitosa.
Los casos de pruebas que se deben cumplir son:
-
El usuario debe poder ver la ruta para llegar al colegio con el fin de poder
apreciar la ruta más cercana.
Por otra parte, el usuario deberá poder ver ubicación de los colegios en el
mapa
El usuario debe ser capaz de visualizar la información del colegio que el
desee.
El administrador podrá ingresar modificar y borrar un colegio.
147
-
El usuario podrá realizar una búsqueda acuerdo a los criterios
seleccionados desplegándose los colegios según criterios.
El usuario podrá a partir de los criterios apreciar la cantidad de me gusta
que posee cada colegio.
El administrador deberá ingresar por un login.
En caso de que el usuario no pueda realizar al menos uno de los casos
mencionados, se considerara una liberación no exitosa.
2.12.34
Evidencia Línea base
La siguiente Imagen Nº9 corresponde a la línea base que se encuentra disponible
en SVN.
Imagen Nº9
148
2.12.35
Burndown
Este grafico Burndown que corresponde al Sprint Nº3 es una herramienta
que nos muestra como el equipo de trabajo fue trabajando bajo la estimación
realizado en el Sprint Backlog Tareas .Se puede apreciar que el equipo de trabajo
se mantuvo sobre el la estimación lo que no es un buen índice, ya que se podría
apreciar que el equipo no cumplió con el total de horas de trabajo por día.
Gráfico Nº3BurnDown Sprint Nº3
2.12.36
Evolución de los Riesgos
Como es de costumbre los riesgos son una amenaza muy importante si no
se les realiza el debido seguimiento y es por eso que semana a semana nosotros
vamos realizando un seguimiento a los riesgos, para así poder ver que riesgos
han disminuidos o que riesgos han aumentado lo que nos permitiría en éste último
caso activar nuestros planes de contingencia o mitigación. Como se Puede
apreciar en la figura a continuación se les realiza semana a semana un exhaustivo
149
seguimiento en donde se indica la probabilidad de que vaya ocurrir dicho riesgo.
Como se puede ver hay ciertos riesgos que disminuyeron su probabilidad como lo
es el caso del Riesgo Nº16 y otros que aumentaron como es el caso del Riesgo
Nº18.
Tabla 35:
Evolución de los Riesgos Sprint Nº3
150
2.12.37
Post Mortem
Luego de realizar este Sprint Nº3 y con ya claro conocimiento del proyecto
el haber manejado gran parte del Sprint Nº1 con gran eficacia al igual que el Sprint
Nº2.Creemos que mejoramos mucho en lo que es tema de pruebas. Anteriormente
no se definía ninguna prueba y claramente en el Sprint Nº3 no podía volver a
pasar y es por eso que ocupamos la herramienta JMeter para realizar pruebas que
fueran de calidad. Sin lugar a dudas la velocidad del equipo fue mejor pero lo que
no nos dejó conforme nuevamente fue las pruebas que ejecutamos a éste Sprint
debido a que podría haberse simulado mejor y mayor calidad en las pruebas.
151
Capítulo V
2.13 Conclusiones
2.13.1 Trabajo futuro
Dentro de nuestro trabajo futuro comprenderá de realizar el cuarto Sprint
para nuestro proyecto, el cual comprenderá de realizar las historias de usuario
especificadas en el Product Backlog.
5.13.2 Conclusiones
Sin lugar a dudas estos tres primeros Sprint nos dan la pauta de los errores
y las mejoras que hemos cometido en cada uno de ellos. Sin embargo hemos
analizado al final de cada Sprint dichos errores y mejoras que podemos realizar
tanto en la gestión del proyecto como en el desarrollo de éste. Es por eso que
como conclusión obtenemos que no es un proyecto fácil, sin embargo poco a
poco nos seguimos motivando y trabajando arduamente para poder lograr
tener un producto en donde la gente pueda utilizar de gran manera. Como
cualquier proyecto se presentan complicaciones para la realización de éste y
sin lugar a dudas en nuestro caso el Sprint Nº3 nos fue extremadamente difícil
ya que se presentó un nuevo riesgo, sin embargo fuimos capaces de sacar
adelante este Sprint Nº3.
Conversando con distinto tipo de gente y nuestro PO se han dado ideas de
agrandar este gran proyecto, es por eso que estamos pensando la posibilidad
de recopilar todos los datos generados y empezar a distribuir esos datos a los
colegios, siendo para ellos un gran material.
152
Anexo Plan de Pruebas
Faceschool
Plan de Pruebas
Versión 1.0
153
Historial de Revisión
Fecha
Versión
Descripción
03/10/2014
1.0
Creación del
documento
Autor
●
●
Daniel Labra
Fernando Figueroa
154
Plan de Pruebas
1.
Introducción
1.1
Propósito
El propósito del plan de pruebas planteado en este documento, es permitir
definir los lineamientos a seguir para realizar la planeación de la etapa de
pruebas sobre el proyecto “FaceSchool”, planteando una estrategia que
conduzca al objetivo enfocado en el aseguramiento de calidad del software.
1.2
Alcance
El plan maestro de pruebas describe el detalle de las diferentes pruebas a ser
aplicadas, así como también las herramientas y metodologías a utilizar en cada
una de estas. Las pruebas que serán realizadas son:
●
Revisión de la documentación: Consiste en revisar la calidad y completitud de
los documentos insumo y casos de uso para la ejecución de las pruebas.
●
Pruebas Unitarias: Se validaran las piezas individuales del software como una
unidad independiente.
●
Pruebas de integración: Se validara la integración entre los diferentes módulos
que componen la solución con el fin de garantizar que su operación integrada
es correcta.
●
Pruebas Funcionales o de Procedimientos: Se validaran los procesos, reglas
de negocio establecidas y los requerimientos funcionales.
●
Pruebas de sistema: Las pruebas de sistema se determinarán en el momento
que el Outsourcing de Desarrollo entregue el documento de Requerimientos no
funcionales, y así determinar qué tipos de prueba se realizarán y a qué casos
de uso se aplicarán.
●
Pruebas de Carga: Se validara que el sistema mantenga su correcta
funcionalidad cuando se someta a pruebas de carga.
●
Pruebas de Aceptación: Se validara que el sistema sea aceptado por el cliente
según las pruebas de aceptación.
155
1.3
Audiencia
Este plan maestro de pruebas está dirigido a todas aquellas personas
involucradas en la planeación, aprobación y ejecución del mismo.
2.
Misión de las Pruebas
2.1
Contexto del Proyecto y Antecedentes
Se pretende realizar un levantamiento y análisis de información de los
procesos de gestión de solicitudes del Banco de los Alpes con el fin de plantear
una arquitectura de solución tecnológica con el fin de optimizar la gobernabilidad,
monitoreo y eficiencia, tanto a nivel técnico como funcional de estos procesos de
negocio que constituyen y representan valor en las objetivos estratégicos de la
organización.
2.2
Misión de las Pruebas aplicable a este proyecto
La misión de la evaluación para el presente proyecto se define enfocada al
aseguramiento de la calidad de los componentes y artefactos tecnológicos
desarrollados, de manera que estos cumplan con la especificación de los
requerimientos del cliente. Para esto se definen los siguientes lineamientos que
constituyen la misión y objetivos dentro este esfuerzo de pruebas:
● Descubrir tantos errores como sea posible
● Notificar acerca de los riesgos percibidos del proyecto
● Examinar la aplicación para comprobar si hace o no lo que se supone, debe
hacer. De igual forma verificar si ésta hace o no lo que se supone, no debe
hacer.
● Validar y Verificar a través de la comparación del resultado de las pruebas del
aplicativo con el resultado que el mismo tendría que producir de acuerdo a su
especificación.
● Evaluar la calidad del producto y satisfacción de los interesados
● Cumplir con los requerimientos del cliente
156
El proceso de evaluación y pruebas debe permitir detectar problemas desde el
inicio de la especificación de requerimientos, antes de que sean de gran impacto
en fases más adelantadas del proyecto, esto con el fin de disminuir los riesgos y
de obtener un producto con calidad logrando mayor satisfacción del cliente.
Elementos Objetivo de Pruebas
A continuación se listan los elementos (artefactos, entregables, documentos etc.)
que seran objeto de prueba dentro del esfuerzo de pruebas:
Fase Inicial
● Documentación
● Especificación de Requerimientos
● Estimaciones
● Modelos - Diagramas
3.
Enfoque de las Pruebas
El plan de pruebas se basará en su totalidad en pruebas funcionales,
instalación, regresión y otras teniendo en cuenta los requerimientos no
funcionales.
Revisión de la documentación: La estrategia para realizar estas pruebas,
consiste en la revisión de la documentación y casos de uso verificando su
completitud y concordancia en la información que se encuentra en ellos.
●
Pruebas unitarias: Las estrategias para realizar estas pruebas consiste en
generar casos de prueba necesarios:
●
Para que cada sentencia o instrucción del programa se ejecute al menos
una vez correctamente.
●
Para que cada condición tenga por lo menos una vez un resultado
verdadero y al menos una vez uno falso.
●
Para probar varias veces el mismo bucle (en donde aplique)
157
considerando los siguientes casos: Ignorar el bucle, pasar una vez,
pasar dos veces, pasar n veces, pasar n-1 veces y n+1 veces.
●
Pruebas funcionales o de procedimientos: La estrategia para realizar estas
pruebas consiste en la elaboración y ejecución de Set de Pruebas, teniendo en
cuenta flujo normal y flujos alternativos, usando datos validos e inválidos que
permitan verificar lo siguiente:
●
●
Los resultados esperados ocurren cuando se usan datos válidos.
●
Se despliegan mensajes de error cuando se usan datos inválidos.
●
Cada regla de negocio es propiamente aplicada.
Pruebas de Regresión: La estrategia para realizar estas pruebas consiste en
repetir las pruebas (funcionales y de carga) ejecutadas antes de corregir
defectos o de añadir nuevas funcionalidades, para comprobar que las
modificaciones no provocan errores donde antes no los había.
3.1
Pruebas de Aceptación
Las pruebas de aceptación se basarán en su totalidad en pruebas funcionales,
instalación, y otras teniendo en cuenta los requerimientos funcionales las pruebas.
Adicionalmente estas pruebas serán de caja negra.
●
Pruebas funcionales o de procedimientos: La estrategia para realizar estas
pruebas consiste en la elaboración y ejecución de Set de Pruebas, teniendo en
cuenta flujo normal y flujos alternativos, usando datos validos e inválidos que
permitan verificar los casos de prueba.
3.3 Técnicas y Herramientas de Prueba
A continuación se exponen las herramientas y técnicas que se usaran para
llevar a cabo las pruebas enfocadas a la mitigación de los riesgos anteriormente
158
planteados:
Factor
de Conformidad
Técnica:
Prueba:
Pruebas
de
operación
Descripción:
Con las pruebas de operación se garantiza que el usuario está bien capacitado
en el manejo del software y además se lleva un registro para guardar los
caminos no contemplados dentro de las pruebas previas del software, y con ello
se tomarán las medidas adecuadas.
Factor
de Facilidad de Uso
Técnica:
Walkthroughs
Prueba:
Descripción:
Se debe incluir al cliente y/o usuario final con un role de evaluador durante
sesiones de walkthroughs en las cuales se discutirán los escenarios de calidad
referentes a la usabilidad del software.
Factor
Prueba:
de Facilidad
Operación
de
Técnica:
Pruebas
de
Requerimientos
Descripción:
Validar los requerimientos no funcionales de ambiente recolectados con el
cliente versus las características requeridas por el ambiente de producción.
3.4 Pruebas de Integración
Las pruebas de integración que se realizaran durante el proceso de desarrollo
de los componentes de software, deben seguir las siguientes políticas y
lineamientos de ejecución:
159
●
Se tiene una fase de pruebas unitarias completa y aprobada para el inicio de
las pruebas de integración.
●
Se seguirá el enfoque “Bottom-UP” para la ejecución de estas pruebas, es
decir, se probaran en primer lugar los componentes o módulos individuales del
software y posteriormente y de manera progresiva se irán agrupando hacia
arriba y de manera funcional estos componentes para probar escenarios que
impliquen varias funcionalidades de interacción entre los componentes, y se
continuará así hasta llegar al nivel más alto de funcionalidad e integración.
●
Dichas pruebas se realizaran únicamente cuando hayan dos o más
componentes a integrar.
●
Para la ejecución de estas pruebas se utilizarán las siguientes técnicas:
Objetivo
de
técnica:
la Verificar el funcionamiento interno de los componentes
desarrollados por medio de la comprobación del los
procedimientos llevados a cabo por el software en cada
invocación/llamado/respuesta, asi como el procesamiento
de datos que tiene lugar en cada uno de esta acciones.
Técnica
Pruebas de Caja negra
Herramientas
●
Debuggers
requeridas:
●
Robot de Pruebas
●
Bug Tracker
●
Tracing y Seguimiento a variables
●
Concordancia de los procedimientos del sistema con los
Criterio de éxito
requerimientos de usuario
●
Optimo manejo de excepciones y errores
●
Fácil seguimiento de la ejecución por medio de los
160
traces.
Objetivo
de
técnica:
la Verificar que los componentes funcionen adecuadamente
de manera individual cuando se encuentran integrados con
otros módulos y componentes
Técnica
Pruebas de Regresión
Herramientas
●
Casos de Prueba
requeridas:
●
Robot de Pruebas con scripts ya ejecutados
●
Bug Tracker
●
Tracing
●
No se detectan errores inyectados durante la integración
Criterio de éxito
del sistema
Objetivo
técnica:
de
la Verificar que la parametrización de componentes y todos los
aspectos referentes a la integración de partes del software
(consideraciones, configuraciones,ajustes) cumplan con lo
preestablecido pro el equipo desarrollo en la fase de diseño.
Técnica
Listas de Chequeo
161
Herramientas
Listas de chequeo con los items a comprobar para la
requeridas:
integración
Criterio de éxito
●
El 100% de los ítems han sido chequeados y cumplen
con la condición para ser aprobados.
Finalmente y como criterio de aceptación para esta fase de las pruebas se
realizará un piloto funcional de la solución construida, para el cual se debe generar
un Set de casos de prueba que abarquen la mayor cantidad de interacciones que
impliquen comunicación e integración entre los diferentes componentes del
software, y en el deben participar tanto los usuarios finales como los
desarrolladores.
4 Necesidades de Ambiente
4.1 Hardware Base para ambiente de pruebas
La siguiente tabla relaciona los recursos de hardware que son necesarios
para crear un ambiente inicial de pruebas en este proyecto.
Equipo
Procesador
DD
PC
superior)
Aplicación
a
Instalar
Navegador
Windows
(XP
RAM
o
Intel
10GB
2 GB Chrome,Mozila
o explorer.
162
4.2 Software Base para ambiente de pruebas
El software a instalar en el equipo de pruebas es:
● Windows 7 o superior
● Explorador a elección(Explorer,Chrome o Mozila)
4.3 Herramientas de soporte a las pruebas
Las siguientes son herramientas a utilizar para la ejecución de las pruebas
y la administración de sus resultados
Categoría o Tipo
Nombre
Pruebas Unitarias
PHP Unit
4.4 Configuraciones de Ambientes de Pruebas
El ambiente de pruebas será en una oficina equipada con las siguientes
herramientas y tecnología:
4
Tablet Samsung Galaxy Tab 3 10’ pulgadas con sistema operativo Android
4.1, con procesador Dual Core.
5
Notebook HP, procesador Intel Core i5 con 6GB de RAM con sistema
operativo Windows 7.
6
Notebook Samsung, procesador Intel Core i7 con 8 GB de RAM y Sistema
operativo Windows 7.
7
Servidor(distinto al de desarrollo)
La oficina se encuentra con acceso a internet para que todos los dispositivos se
puedan conectar a la red. Además contara con dos escritorios y una pequeña
mesa para realizar las distintas reuniones programadas.
163
5. Datos de Prueba
Con el objetivo de realizar unas pruebas acertadas y lo más cercanas a la
realidad que sea posible, es necesario contar datos que alimenten la ejecución de
los casos de prueba, los cuales, en la medida de lo posible, deben ser reales,
cubrir un rango considerable y representar una profundidad significativa dentro del
dominio de los datos que maneja la organización en los procesos de negocio
involucrados.
164
Anexo Encuesta Nº1
A continuación como anexo se mostrara la encuesta Nº1 que se realizó a
30 padres o tutores escogidos aleatoriamente. Esta encuesta nos permitió obtener
un feedback respecto a lo que los futuros usuarios quieren o esperan como
Faceschool.
Resumen
¿Qué colegio prefiere?
Publico
5
Subvencionado
9
Privado
15
¿Qué formación religiosa desearía que tenga el colegio?
Católica
11
Luterana
1
No es relevante
Otro
15
2
165
Para usted, ¿Que idiomas debe tener el colegio?
Ingles
11
Alemán
0
Francos
0
Italiano
0
Otro
1
¿Es relevante la infraestructura a la hora de matricular a su alumno en
algún colegio?
Si
24
No
5
Nombre 3 características esenciales en las cuales usted se fija al
buscar un colegio.
Bilingüe Acceso universidad Permanencia universidad
infraestructura, Precio e Historia
Acceso relacionado con la ubicación Infraestructura Tecnológica Preparación de los profesores
Buena educación Buena infraestructura Buenos profesores
Buenos profes, mucho deporte y talleres
Valores que pretenden inculcar Ubicación En el caso de ser religioso, qué tan extremista es.
Deportes Intercambios Idiomas
Buenos profesores
Cercanía a mi hogar, buen ambiente, infraestructura
166
Buenos profesores, Buen ambiente
Idiomas, calidad de los profesores y alumnos
Docentes con experiencia y buen ambiente.
Puntajes PSU Ambiente Escolar Trato Docente
Infraestructura Lugar Arancel
Localidad Profesorado Infraestructura Medios
Buena infraestructura, buenos docentes y bueno resultados en simces.
Calidad en los contenidos educacionales actividades extra programáticas reputación
buen ambiente, status social
Buenos profesores, entreguen almuerzo.
Calidad de los profesores, buen ambiente y simpatía de los profesores
¿Qué le interesa saber sobre un colegio?(seleccione por nivel de
importancia)
Puntaje Simce
Religión
18
6
Infraestructura
16
Cantidad de alumnos por clase
11
Otro
7
¿Es relevante la cercanía del establecimiento a la hora de matricular a
su hijo/a?
Si
21
No
8
¿Resulta esencial tener un gabinete psicopedagógico ayuda en el caso
de que el alumno presente alguna dificultad de aprendizaje?
167
Si
17
No
12
¿Desearía encontrar gran parte de los colegios ubicados en un
determinado sector en base a ciertas características?
Si
25
No
4
Si pudiera ver todos los colegios de la zona en una sola pagina web
¿Qué características le gustaría ver para poder tomar una decisión al
momento de matricular a su hijo/a en ese colegio?
Resultados psu. Ranking de colegios regional y nacional. Fotos. Aranceles. Vacantes
Contacto directo hacia el colegio.
NEM Puntaje PSU
Tiempo y distancia de recorrido y transportes escolares que hay y el recorrido de ellos.
Fotos de la infraestructura, aranceles, puntajes simces.
Religión sobre todo, infraestructura
1 - Precio de matrículas y aranceles. 2 - Una que otra entrevista sobre el colegio hacia algún
profesor o cargo importante de la institución. 3 - Pequeña reseña con historia del establecimiento.
Trayectoria del colegio
Infraestructura cantidad alumnos por clases mision y vision
Precio, matricula, arancel vacantes disponibles Prerequisitos de ingreso
Arancel Número de niños por cursos Número de cursos por nivel Enfoque pedagógico
Puntaje Simce Fotos del establecimiento Vacantes
Infraestructura Metros cuadrados construidos, y de patio. Profesores
168
A su juicio le gustaría ver dicha información en una página web o una
aplicación para Smartphone
En una página web
En una aplicación para Smartphone
21
2
¿Tiene alguna herramienta para la búsqueda de colegios?
Si
1
No
11
Encuentra difícil las herramientas que utiliza hoy en día para buscar
colegios?
169
Si
No
11
5
170