SOIA: Soporte a las Operaciones para empresas de Imágenes Aéreas

(1)

Universidad ORT Uruguay

Facultad de Ingeniería

SOIA: Soporte a las Operaciones para

empresas de Imágenes Aéreas

Entregado como requisito para la obtención del título de Licenciado en Sistemas de la

Información

Ariel Carámbula - 94702

Carolina Martínez - 127154

Esteban Levy - 146820

Tutor: Marcelo Cagnani

(2)

2

Declaración de Auditoría

Nosotros, Ariel Carámbula, Carolina Martínez y Esteban Levy, declaramos que el trabajo que

se presenta en esa obra es de nuestra propia mano. Podemos asegurar que:

 La obra fue producida en su totalidad mientras realizábamos el proyecto de grado;

 Cuando hemos consultado el trabajo publicado por otros, lo hemos atribuido con

claridad;

 Cuando hemos citado obras de otros, hemos indicado las fuentes. Con excepción de

estas citas, la obra es enteramente nuestra;

 En la obra, hemos acusado recibo de las ayudas recibidas;

 Cuando la obra se basa en trabajo realizado conjuntamente con otros, hemos explicado

claramente qué fue contribuido por otros, y qué fue contribuido por nosotros;

 Ninguna parte de este trabajo ha sido publicada previamente a su entrega, excepto

donde se han realizado las aclaraciones correspondientes.

Ariel Carámbula Carolina Martínez Esteban Levy

(3)

3

Agradecimientos

En primer lugar queremos agradecer a nuestro tutor, Marcelo Cagnani, por el apoyo brindado

a lo largo del proyecto.

También a los revisores que nos aconsejaron en las diferentes etapas del proyecto para

mejorar el trabajo realizado.

A Ricardo Mesa y a todos los integrantes de 2000 Aviation Systems por la disponibilidad y

paciencia a lo largo del proyecto. Por ayudarnos a aplicar en la vida real, todos los

conocimientos adquiridos en el ámbito académico.

Por último, pero no menos importante, a nuestras familias y amigos que nos dieron el apoyo

(4)

4

Abstract

Nuestro cliente 2000 Aviation Systems es una empresa dedicada a la fotografía aérea digital

que cuenta con más de 15 años de experiencia en Uruguay y la región. Su trayectoria,

experiencia adquirida, e innovación en productos de calidad para el medio, los mantiene

siempre a la vanguardia de la geoinformación y la fotogrametría.

El producto realizado es SOIA (Soporte a las operaciones para empresas de imágenes aéreas)

que sustenta los principales procesos de la compañía: cotización, panificación, vuelo y

procesamiento.

Para realizar el proyecto decidimos utilizar una metodología con características ágiles debido a

que nos permitía en forma temprana tener avances sobre el producto final lo que se consideró

necesario en función de las características del cliente y del producto. En relación a la gestión

del proyecto optamos por utilizar Scrum.

El proyecto demandó grandes desafíos tecnológicos como lo son componentes de base de datos

espaciales e interacción con componentes geo referenciales logrando integrar todos estos

componentes en una única solución para el usuario.

Con la aplicación SOIA, 2000 Aviation Systems podría obtener beneficios tangibles que

permitirá a través del registro ordenado de datos del negocio, recuperación de información

valiosa accediendo y manipulando base de datos espaciales, procesamiento de información con

(5)

5

Palabras Clave

 2000 Aviation Systems

 Proyecto

 Scrum

 Geoespacial

(6)

6

Índice

GLOSARIO ... 12

1. INTRODUCCIÓN ... 18

1.1. ENTORNO CONCEPTUAL DE SOFTWARE FACTORY Y SUS OBJETIVOS ... 18

1.2. OBJETIVO DEL PROYECTO ... 19

1.3. EL CLIENTE ... 19

1.3.1. Misión ... 20

1.3.2. Productos destacados ... 20

1.4. EL EQUIPO ... 22

1.5. ESTRUCTURA DEL DOCUMENTO Y CONTENIDO DEL CD ... 22

2. PLANTEO DEL PROBLEMA ... 25

2.1. CONTEXTO DEL PROBLEMA ... 25

2.1.1. Etapa Cotización (1) ... 27

2.1.1.1. Hallazgos de cotización ... 28

2.1.2. Etapa Planificación (2) ... 29

2.1.2.1. Hallazgos de planificación ... 31

2.1.3. Etapa Vuelo (3) ... 31

2.1.4. Etapa Procesamiento (4) ... 32

2.1.5. Etapa Producto final y entrega (5 y 6) ... 32

2.2. TIPO DE USUARIOS Y NECESIDADES ... 33

3. ENFOQUE DE LA SOLUCIÓN ... 34

3.1. OBJETIVOS GENERALES DEL PRODUCTO ... 34

3.2. DESCRIPCIÓN FUNCIONAL DEL PRODUCTO ... 35

3.2.1. Página principal ... 35

3.2.2. Módulo de administración de las cotizaciones ... 36

3.2.2.1. Alta de cotización ... 36

3.2.2.2. Consulta de cotización ... 40

3.2.2.3. Edición de cotización ... 43

3.2.2.4. Descarga de archivo geoespacial ... 45

3.2.3. Módulo de administración de planificaciones ... 45

3.2.3.1. Alta de planificación ... 45

3.2.3.2. Edición de planificación ... 47

3.2.3.3. Baja de planificación ... 48

3.3. BENEFICIOS DE LA SOLUCIÓN ... 48

(7)

7

4.1. CICLO DE VIDA ... 50

4.2. METODOLOGÍA ... 51

5. INGENIERÍA DE REQUERIMIENTOS ... 53

5.1. JUSTIFICACIÓN DE LA METODOLOGÍA DE RELEVAMIENTO ... 53

5.2. CRITERIOS DE PRIORIZACIÓN DE REQUERIMIENTOS ... 54

5.3. ESTRUCTURA UTILIZADA PARA LA ESPECIFICACIÓN ... 55

5.4. REQUERIMIENTOS FUNCIONALES ... 56

5.5. REQUERIMIENTOS NO FUNCIONALES ... 58

5.6. USUARIOS DEL SISTEMA ... 60

6. ARQUITECTURA ... 61

6.1. ATRIBUTOS DE CALIDAD ... 61

6.1.1. Priorización de los atributos de calidad ... 61

6.2. DESCRIPCIÓN ARQUITECTÓNICA ... 67

6.2.1. Vista de asignación... 67

6.2.1.1. Diagrama de despliegue ... 67

6.2.1.1.1. Representación primaria... 67

6.2.1.1.2. Catálogo de elementos ... 68

6.2.1.1.3. Decisiones de diseño arquitectónico ... 69

6.2.2. Vista de despliegue (deploy) ... 70

6.2.2.1. Diagrama de paquetes ... 70

6.2.2.1.1. Representación primaria – Diagrama web ... 70

6.2.2.1.1.1. Catálogo de elementos ... 71

6.2.2.1.2. Representación primaria – Diagrama servicios ... 72

6.2.2.1.2.1. Catálogo de elementos ... 73

6.2.2.2. Decisiones de diseño arquitectónico ... 74

6.2.2.3. Diagrama de componentes y conectores ... 74

6.2.3. Vista lógica ... 76

6.2.3.1. Diagrama de clases del negocio ... 76

6.2.3.2. Diagrama de clases de los servicios ... 79

(8)

8

6.2.3.3. Diagrama de clases de los DAO ... 83

6.2.3.4. Diagramas de secuencia ... 87

6.2.3.4.1. Alta de Cotización ... 87

6.2.3.4.2. Adjuntar archivo SHAPE, KML/KMZ a la cotización. ... 88

6.3. PATRONES ARQUITECTÓNICOS UTILIZADOS ... 92

6.3.1. Patrón de capas lógicas ... 92

6.3.2. Patrón de capas físicas (4-Tier) ... 94

6.3.3. Patrón SOA ... 95

6.3.4. Patrón Model-View-Controller ... 97

6.3.5. Inyección de dependencias ... 97

6.3.6. Intercepting filter... 98

6.4. TECNOLOGÍAS UTILIZADAS ... 99

6.5. ESTRATEGIA DE DESARROLLO... 105

6.5.1. Equipo de desarrollo ... 105

6.5.2. Modus operandi ... 106

7. CALIDAD ... 107

7.1. INTRODUCCIÓN ... 107

7.2. OBJETIVOS DE LA CALIDAD ... 108

7.3. PROCESO DE ASEGURAMIENTO DE LA CALIDAD ... 108

7.4. ESTÁNDARES, CONVENCIONES Y MÉTRICAS ... 113

7.4.1. Estándares ... 113

7.4.1.1. Gestión de proyecto ... 113

7.4.1.2. Desarrollo ... 114

7.4.1.3. Documentación del proyecto ... 114

7.4.2. Métricas ... 114

7.5. CONCLUSIONES DE CALIDAD ... 115

7.5.1. Registro, análisis y resultados de la medición de métricas. ... 116

8. TESTING ... 118

8.1. TIPOS DE PRUEBAS ... 118

8.2. ESTRATEGIAS DE PRUEBAS ... 120

(9)

9

8.3.1. Incorporación al proceso general de desarrollo del proyecto ... 121

8.3.2. Gestión de incidentes ... 122

8.3.3. Métricas de pruebas ... 124

8.3.3.1. Resultados y conclusiones de las métricas ... 124

9. GESTIÓN DE LA CONFIGURACIÓN - SCM ... 128

9.1. INTRODUCCIÓN ... 128

9.2. PROPÓSITO ... 128

9.3. RESPONSABILIDADES ... 128

9.4. ACTIVIDADES DE SCM ... 129

9.4.1. Identificación de los elementos de la configuración... 129

9.4.2. Nomenclatura de los elementos ... 130

9.4.3. Control de la configuración ... 131

9.4.4. Control de cambios ... 132

9.4.5. Backup ... 134

9.5. RECURSOS ... 134

9.6. MANTENIMIENTO DEL PLAN DE SCM... 135

10. GESTIÓN ... 136

10.1. MARCO DE TRABAJO ... 136

10.2. ETAPAS DEL PROCESO... 137

10.2.1. Planificación del sprint... 137

10.2.2. Seguimiento del sprint ... 139

10.2.3. Cierre del sprint ... 139

10.3. METODOLOGÍA ADAPTADA ... 140

10.4. ROLES Y RESPONSABILIDADES... 143

10.5. CRONOGRAMA ... 144

10.5.1. Etapas del proyecto ... 144

10.5.1.1. Etapa inicial o Sprint 0 ... 144

10.5.1.2. Iteraciones ... 147

10.5.1.3. Documentación ... 149

10.6. GESTIÓN DE LA COMUNICACIÓN ... 149

10.6.1. Comunicación y coordinación del equipo ... 149

10.6.2. Comunicación interna con el equipo ... 149

10.6.3. Comunicación externa ... 150

10.7. GESTIÓN DE RIESGOS ... 151

10.7.1. Principales Riesgos ... 151

(10)

10

10.8. RESUMEN DE LOS SPRINTS ... 154

10.9. SEGUIMIENTO DE LOS SPRINTS ... 155

10.9.1. Criterios de evaluación de sprint ... 155

10.9.2. Sprint 0 ... 156

10.9.2.1. Análisis de métricas ... 156

10.9.2.2. Análisis causal de los problemas ... 156

10.9.2.3. Conclusiones e identificación de mejoras ... 156

10.9.3. Sprint 1 ... 156

10.9.3.1. Evaluación del sprint ... 157

10.9.4. Sprint 2 ... 158

10.9.5. Sprint 3 ... 161

10.9.6. Sprint 4 ... 162

10.10. ANÁLISIS Y RESULTADOS DE LA EVOLUCIÓN DE LAS MÉTRICAS Y PROBLEMAS DE GESTIÓN ... 164

10.11. DECISIONES IMPORTANTES TOMADAS DURANTE EL PROYECTO ... 168

11. LECCIONES APRENDIDAS Y CONCLUSIONES ... 169

11.1. LECCIONES APRENDIDAS ... 169

11.2. CONCLUSIONES ... 171

12. REFERENCIAS BIBLIOGRÁFICAS ... 173

13. ANEXO I – TEMPLATE COTIZACIÓN ... 176

14. ANEXO II – PRODUCT BACKLOG FINAL ... 177

(11)

11

15.1. TEMPLATEENCUESTA DE USABILIDAD DE NIELSEN ... 185

15.1. EVIDENCIA -ENCUESTAS DE USABILIDAD DE NIELSEN ... 185

15.1.1. Sprint 2 - Encuesta 1 ... 185

15.1.2. Sprint 2 - Encuesta 2 ... 186

15.1.3. Sprint 3 - Encuesta 1 ... 187

15.1.4. Sprint 3 - Encuesta 2 ... 187

15.1.5. Sprint 4 - Encuesta 1 ... 188

15.1.6. Sprint 4 - Encuesta 2 ... 189

16. ANEXO IV – EVIDENCIA - ENCUESTA DE SATISFACCIÓN ... 190

17. ANEXO V – EVIDENCIA DE CASOS DE PRUEBAS ... 191

17.1. CASOS DE PRUEBA – SPRINT2 ... 191

17.2. CASOS DE PRUEBA – SPRINT3 ... 199

17.3. CASOS DE PRUEBA - SPRINT4 ... 205

18. ANEXO VI – BUGS Y CORRECCIONES ... 212

19. ANEXO VII - DOCUMENTO DE CIERRE DE SPRINT ... 219

20. ANEXO VIII - GESTIÓN Y SEGUIMIENTO DE RIESGOS ... 240

20.1. PLANIFICACIÓN DE LOS RIESGOS ... 240

20.2. IDENTIFICACIÓN DE LOS RIESGOS ... 241

20.3. ANÁLISIS CUANTITATIVOS ... 241

20.4. PLANIFICACIÓN DE LA RESPUESTA A RIEGOS ... 241

20.5. SEGUIMIENTO DE RIESGOS ... 243

21. ANEXO IX – PROTOTIPOS DE INTERFACES ... 285

22. ANEXO X - SPRINTS BACKLOG ... 299

22.1. SPRINT 1 ... 299

22.2. SPRINT 2 ... 301

22.3. SPRINT 3 ... 305

22.4. SPRINT 4 ... 308

23. ANEXO XI - OBJETOS ESPACIALES Y GEOGRÁFICOS, POSTGIS ... 312

(12)

12

Glosario

A

Api: Application Programming Interface, conjunto de funciones y procedimientos que ofrece cierta biblioteca para ser utilizado por otro software.

Apk: Application PacKage File, paquete para el sistema operativo Android. Este formato es una variante del formato JAR de Java y se usa para distribuir e instalar componentes

empaquetados para la plataforma Android en smartphones y tablets.

B

Base de datos espacial: Sistema administrador de bases de datos que maneja datos existentes

en un espacio o datos espaciales.

C

CSS: Cascading Style Sheets, hojas de estilo en cascada. Es un estándar que sirve para la construcción y elaboración de los estilos y gráfica de las páginas web construidas en el lenguaje

HTML.

D

Daily meeting: Término en inglés usado para referirse a una de las ceremonias del sprint. Esta ceremonia es diaria, y consiste en que cada miembro del equipo informe al resto el estado de

las tareas en las que están trabajando, y con cuáles seguirán luego de que las finalicen.

(13)

13

E

Epic Story: Término que consiste en una o más frases, que representa un requerimiento que el usuario desee que su producto cumpla, pero sin incluir detalles, por lo que luego deberá ser

descompuesto en User Stories.

Escalabilidad horizontal: Significa agregar más nodos a un sistema. Añadir recursos de

manera casi infinita y adaptable al crecimiento de cargas de trabajo y nuevos usuarios.

F

Framework: Marco de trabajo que define un conjunto de conceptos estandarizados para

resolver un tipo de problema en particular. Generalmente sirve como referencia para resolver

problemas similares ofreciendo un conjunto de herramientas para facilitar su implementación.

G

Geoespacial: O georreferenciación, consiste en ubicar un objeto en el espacio tridimensional

con respecto a la tierra utilizando un sistema de coordenadas y un DATUM determinado. Su

principal uso consiste en establecer las relaciones entre las imágenes raster y vectoriales en un

sistema de coordenadas. Además de determinar el lugar en el espacio de las elementos

geográficos, permite establecer la correcta posición de una fotografía aérea en un mapa y

determinar la exacta ubicación de un punto en una fotografía o imagen; como por ejemplo,

encontrar las coordenadas de un lugar específico, la distancia entre un punto a otro, etc. Este

procedimiento es de gran importancia para los modelos de información en el campo de los

sistemas de información geográficos (SIG), ya que funciona como fuente de información

directa y precisa.

GIS: Geographic Information System, sistemas de información geográfica. Son un conjunto de herramientas de hardware y software los cueles permiten el almacenamiento, manipulación,

análisis y modelización de datos vinculados a una referencia espacial.

(14)

14

HTTP: Hypertext Transfer Protocol, protocolo de transferencia de hipertexto. Protocolo sin estado que define sintaxis y semántica utilizada por elementos de software en arquitectura web.

J

Jar: Java Archive, arvhivo Jar. Tipo de archivo que permite ejecutar aplicaciones escritas en el lenguaje Java.

Json: JavaScript object notation, notación de objetos de JavaScript. Es un archivo de formato liviano de intercambio de datos. Permite la sencilla interpretación y escritura a través de

lenguajes de programación. Json es un formato de texto que es completamente independiente

del lenguaje pero utiliza convenciones que son ampliamente conocidas por los programadores

de la familia de lenguajes C, incluyendo C, C++, C#, Java, JavaScript, Perl, Python, Php y

muchos otros. Estas propiedades hacen que Json sea un lenguaje ideal para el intercambio de

datos.

K

Kml: Keyhole Markup Language, lenguaje de marcas de Keyhole. Es una gramática XML y

un formato de archivo para la creación de modelos y el almacenamiento de funciones

geográficas como puntos, líneas, imágenes, polígonos y modelos que se mostrarán en Google

Earth, Google Maps y otras aplicaciones.

Kmz: versión comprimida de un archivo KML.

M

Managed bean: Clase java requerida y manejada por el framework JSF.

Mocks: Objetos de reemplazo (orientado a pruebas). Es programado para simular al objeto que reemplaza de una manera simple. Este objeto debe ser provisto a la clase a probar para que ésta

(15)

15

Mockups: Es un modelo utilizado para la demostración, evaluación del diseño, y para otros fines. Muestra en forma estática, aspectos externos del sistema como: pantallas, reportes, etc.

Los mockups son utilizados para la adquisición de comentarios por parte de los usuarios del sistema.

P

POJO: Plain old java object, son clases java simples que no dependen de un framework en especial.

Product Backlog: Término en inglés que se refiere a la lista de tareas estimadas que el equipo deberá realizar durante todo el desarrollo del producto.

Product Owner: Término en inglés que refiere al encargado del proyecto de parte del cliente.

R

Release: Palabra en inglés utilizada para representar la finalización de un producto listo para ser probado por el cliente.

REST: Representational State Transfer, Transferencia de Estado Representacional. Técnica para resolver la comunicación entre sistemas distribuidos como por ejemplo, comunicación vía

Internet.

Retrospective Meeting: Término en inglés que representa una de las ceremonias de cierre de sprint, en la cual todos los miembros del equipo deben reflexionar sobre el sprint que concluye.

(16)

16

S

SGBD: Sistema de gestión de bases de datos. Conjunto de programas que permiten el

almacenamiento, modificación y extracción de la información en una base de datos.

Shape: Formato de archivo vectorial para almacenamiento digital donde se guarda la localización de elementos geográficos y sus atributos.

SOA: Service Oriented Architecture, arquitectura orientada a servicios. Es un paradigma de arquitectura para diseñar y desarrollar sistemas distribuidos.

SOIA: Sistema de soporte a operaciones para empresas de imágenes aéreas.

Sprint: También conocido como “iteración”, un sprint representa una unidad de desarrollo de

duración fija en el marco de trabajo Scrum.

Sprint Backlog: Término que se refiere a la lista de User Stories con sus respectivas tareas que el equipo deberá realizar durante el sprint.

Sprint Planning: Término utilizado para representar una de las ceremonias del sprint. Esta ceremonia se realiza al inicio de cada sprint, y consiste en planificar el Sprint Backlog, seleccionando y estimando las tareas que serán realizadas.

SRID: Spatial Reference System Identifier, identificador de referencia espacial. Corresponde a

un sistema de referencia espacial definido por la norma European Petroleum Survey Group

(EPSG), el cual está basado en el elipsoide concreto usado para la creación de mapas de tierra

plana o de tierra redonda.

T

Testing: Palabra en inglés que hace referencia a la realización de pruebas al software.

(17)

17

User Story: Término que implica una o más frases, que representa un requerimiento detallado que el usuario desea que su producto cumpla.

W

War: Web Application Archive, archivo de aplicación web. Es un archivo utilizado para distribuir páginas Java web, servlets, clases Java, archivos XML, librerías de tags, plantillas de estilos, y páginas web estáticas (HTML o relacionados) que juntos constituyen una aplicación

web.

X

Xml: eXtensible Markup Language (lenguaje de marcas extensible), es un lenguaje

desarrollado por la World Wide Web Consortium (W3C) utilizado para almacenar datos en

(18)

18

1. Introducción

El presente documento tiene por objetivo describir el proceso que se llevó a cabo para el

proyecto final de la carrera Licenciatura de Sistemas de la Universidad ORT Uruguay de los

alumnos Carolina Martínez, Esteban Levy y Ariel Carámbula. El proyecto comenzó 24 de Abril

de Marzo de 2014 y finalizó 11 de Setiembre de 2014. El mismo fue tutorado por Marcelo

Cagnani.

Previo al inicio del proyecto, el equipo consideró distintas opciones para el desarrollo del

mismo. Se evaluaron los proyectos seleccionados por el laboratorio ORT Software Factory y

los que cada uno de los integrantes pudo conseguir de forma personal. Se eligieron 3, entre

todas las opciones posibles y se las ordenó por prioridad en base a nuestra preferencia.

Luego de presentar las propuestas a desarrollar, el laboratorio ORT Software Factory asignó al

equipo el proyecto de SOIA – Soporte a las operaciones para empresas de imágenes aéreas.

En los siguientes capítulos se describe el proceso de desarrollo y gestión realizado durante el

proyecto.

1.1. Entorno Conceptual de Software Factory y sus objetivos

Una de las primeras decisiones era saber en qué laboratorio íbamos a realizar el proyecto. Por

las características de la Software Factory por su misión, visión y política de calidad vimos que

era la mejor opción.

El Laboratorio denominado ORT Software Factory, ORTsf, es una organización académica

dedicada a la enseñanza de prácticas de Ingeniería de Software, a la mejora de procesos de

software, a la transferencia de tecnología a la industria y a la producción de software.

(19)

19

"Ser líderes en la generación de conocimiento sobre la producción de software de calidad. Ser

un referente dentro de la Universidad, en el medio y la región, en la creación y aplicación de

prácticas de ingeniería de software para la producción de productos de calidad."

Misión

"El laboratorio de Ingeniería de Software es una organización abocada a la formación de

profesionales que desarrollen productos que satisfagan a sus clientes, focalizando la atención

en la producción de software de forma industrial y en proveer tecnología probada al mercado"

Política de calidad

“ORT Software Factory es una organización abocada a la producción de software de forma

industrial, focalizando la atención en la formación de profesionales que realicen productos que

satisfagan a sus clientes”.

1.2. Objetivo del proyecto

Proveer a 2000 Aviation Systems una solución tecnológica que permita satisfacer las

necesidades integrando sus procesos de una forma más eficiente. Entendiendo cada una de las

necesidades que nos planteó 2000 Aviation Systems vimos una gran oportunidad de poder

asistirlos en la mejora de sus procesos así como también brindarles una plataforma que integre

la complejidad de su negocio permitiéndoles sacar ventaja de los procesos apoyados en

tecnología.

Realizar un proyecto de sistemas con un cliente real de forma de poder plasmar los

conocimientos académicos y adquirir experiencia. Si bien fue un alto desafío y compromiso el

tener que cumplir con un cliente real, creemos que es una inmejorable oportunidad para aplicar

los conocimientos adquiridos durante los 4 años de la licenciatura.

1.3. El cliente

2000 Aviation Systems es una empresa dedicada a la fotografía aérea digital que cuenta con

(20)

20

Fue la primera empresa en adquirir, en el año 2006, un sistema de fotografía aérea totalmente

digital.

Para la toma y proceso de la información cuentan con el sistema de fotogrametría digital

EnsoMOSAIC, que permite la obtención de mosaicos digitales georreferenciados y

ortorectificados de alta resolución. Para ello se realiza la toma de centros de exposición y

posteriormente la ortorectificación, utilizando los sistemas de la estación fotogramétrica digital

EnsoMOSAIC 3D.

1.3.1. Misión

Proveer un producto y un servicio profesional y competitivo del más alto valor para satisfacer

las más exigentes demandas de nuestros clientes. A su vez creemos en la capacitación de

nuestros clientes para poder ofrecerles nuevos productos de la más alta tecnología disponible

mejorando su valor en el mercado.

Tenemos como objetivo brindar servicios y productos geoinformáticos en todo el Mercosur a

través de la más alta tecnología y de un equipo motivado, analítico, altamente capacitado,

experimentado, e innovador.

1.3.2. Productos destacados

Minería

Las aplicaciones en el campo de la minería permiten un gran manejo de información para el

análisis previo y para el desarrollo de la producción. Brindamos productos de adquisición y

procesamiento de datos, análisis de superficie y geofísica aplicada:

 Geofísica Aérea

 Magnetometría

 Gamma espectrometría

 Gravimetría etc.

(21)

21

Las aplicaciones en el sector forestal permiten controlar la evolución y realizar análisis de las

especies. Monitorear los crecimientos y la salud de los árboles, estimar costos, controlar plagas.

Datos para estimación de biomasa

 Conteo de árboles

 Altura de árboles

 Rodalización de melgas

 Datos para clasificación de especies

 Fotografía Infrarroja

 Estado vegetativo

Urbanismo

Las aplicaciones en esta disciplina permiten estudiar y analizar las ciudades y sistemas urbanos

con gran precisión. La complejidad que presentan las urbes queda simplificada con el manejo

de los sistemas de información geográficos aplicados a este sector.

 Catastro Urbano

 Mapas de desarrollo Urbano

 Control y detección de cambios

 GIS

Agricultura

Las aplicaciones en la agricultura permiten una mejor gestión de los cultivos y de las

plantaciones. Es posible monitorear la evolución de las plantas, permitiendo un mayor control

del crecimiento y de la salud de las mismas.

Aplicando técnicas de agricultura de precisión se consigue predecir con más exactitud la

producción de los cultivos.

 Fotografía aérea.

 GIS para predios agropecuarios.

(22)

22

1.4. El equipo

El equipo estuvo integrado por Ariel Carámbula, Carolina Martínez y Esteban Levy. Tanto

Carolina como Ariel habían participado en alguna materia juntos. Finalmente se unió al equipo

Esteban aportando la oportunidad del desarrollo para 2000 Aviation Systems.

Cabe recalcar como fortaleza del equipo los diferentes perfiles que tienen los integrantes

logrando de esta forma un equipo cohesivo y que se complementa en sus conocimientos y

habilidades. Carolina trabaja como analista programadora en Verifone [1] realizando tareas de

análisis, diseño y desarrollo de aplicaciones Java. Estaban Levy trabaja en Diseño y desarrollo

de soluciones Java con un perfil más técnico en Indra [2]. Ariel Carámbula trabaja en Quanam

[3] en soluciones de Bussines Analytics utilizando base de datos multidimensionales y

relacionales.

1.5. Estructura del documento y contenido del CD

El documento se encuentra organizados de la siguiente forma:

Glosario

Introducción: En este capítulo se brinda al lector un panorama general del contexto del

proyecto.

Planteo del problema: En este capítulo se presenta el contexto del problema describiendo el

flujo de trabajo y la situación inicial identificando hallazgos para las diferentes etapas del

proceso.

Enfoque de la solución: Este capítulo está centrado en como la solución resuelve el problema

planteado y cuáles son los potenciales beneficios que se identificaron.

Ciclo de vida y metodología: Este capítulo brinda el marco metodológico aplicado en el

(23)

23

Ingeniería de requerimientos: Este capítulo brinda al lector un panorama de cómo se

desarrolló el relevamiento de requerimientos, cuáles fueron las prácticas y técnicas utilizadas y

cuáles fueron los requerimientos funcionales y no funcionales.

Arquitectura: En este capítulo se especifica el modelo arquitectónico del sistema a través de

diagramas de arquitectura así como también como los atributos de calidad indicados por el

cliente son sustentados en la solución.

Calidad: En este capítulo se brinda el enfoque de calidad presentando los objetivos, la

planificación y luego qué actividades se llevaron a cabo durante el proceso de desarrollo para

asegurar los criterios de calidad y las conclusiones.

Testing: En este capítulo se detallan las estrategias de pruebas utilizadas y cuáles fueron las diferentes actividades de testing desarrolladas en el proceso. Luego se mencionan las pruebas

realizadas, la evolución de las métricas, los resultados de las mediciones y las principales

conclusiones.

Gestión de la configuración - SCM: En este capítulo se detalla cómo se realizó la gestión de

la configuración del software, qué herramientas se utilizaron y como se realizó la gestión

durante el transcurso del proyecto.

Gestión: Se detalla cómo se realizó la gestión del proyecto indicando los roles y

responsabilidades, el cronograma, un análisis de las diferentes etapas del proyecto desde el

punto de vista de gestión mostrando la evolución y seguimiento, la gestión de las

comunicaciones, gestión de riesgos y un análisis general de resultados y problemas de gestión

identificados.

Lecciones aprendidas y conclusiones: En este capítulo se detallan las principales conclusiones

y lecciones aprendidas que el equipo obtuvo como resultado de todo el proceso. Se incluyen

(24)

24

Anexos: Se presentan todos los documentos relevantes realizados durante el proyecto que

cuentan con información detallada o complementaria a la que conforma el cuerpo central del

documento

En el CD se encuentra el documento principal, llamado “Entrega_SOIA.pdf”, que contiene la

descripción del problema, la descripción del producto construido, el proceso de gestión del

proyecto, los resultados obtenidos y finalmente las conclusiones a las cuales llegaron al finalizar

(25)

25

2. Planteo del problema

El proyecto surge a partir de la necesidad de 2000 Aviation Systems de contar con un producto

que ayudara a organizar su metodología de trabajo ya que estaba poco definidas hasta el

momento.

En las primeras reuniones, se notaba claramente la falta de Estandarización en los procesos, la

inconsistencia entre los empleados sobre cómo debían hacer su trabajo, y desconocimiento

sobre los flujos de debían seguir.

A esta situación se suma el hecho de la complejidad del negocio identificado principalmente

por la manipulación de Tecnologías geo espaciales y objetos geo-referenciales.

Como se describe en este capítulo en la sección de contexto del problema, en cada una de las

etapas del proceso del producto que realiza 2000 Aviation Systems existe una fuerte interacción

con objetos geo-referenciales que permiten determinar representaciones de la superficie del

terreno como son altura, relieves, trazado de perfiles topográficos etc. Dichos objetos son

almacenados en base de datos geo espaciales que almacenan datos espaciales como son puntos,

línea y polígonos. La comprensión de estos objetos, la forma de almacenar, recuperar y

consultar son algunos aspectos de complejidad que presenta el dominio del problema.

Dada esta situación 2000 Aviation Systems desea contar con una solución que apoye cada una

de las etapas del proceso de forma automática logrando optimización, orden y eficiencia en el

ciclo de trabajo. A continuación se describe el ciclo de trabajo y oportunidades de mejora.

2.1. Contexto del problema

Como se mencionó anteriormente 2000 Aviation Systems es una empresa dedicada a la

fotografía y filmación área destacándose entre otros la creación de producto derivados de estas

actividades como son: Magnetometría, Geofísica, fotografía panorámica, Orto imágenes (RGB,

IR,CIR) y lidar. Estos productos son el resultado de un flujo de trabajo que a grandes rasgos,

comienza con una solicitud del cliente de una cotización, continúa por la planificación, luego

el vuelo, luego el procesamiento que genera el producto final y es entregado al cliente. Este

(26)

26

Figura 2-1 Proceso de negocio

Etapa Proceso Actor

1 Etapa Cotización Solicitud de cotización Cliente

Recepción de archivo

kmz, shape

Encargado

Cotización

Análisis de predios de

acuerdo a arvhivos.

Agrupación de predios

Encargado

Cotización

Nueva generación de

archivos

Encargado

Cotización

Aceptación de cotización Cliente

2 Etapa Planificación Visualización de predios

Encargado de

Planificación

Asociación de archivo nca

a los predios

Encargado de

Planificación

Registro de planificación

Encargado de

Planificación

3 Etapa de Vuelo Vuelo del predio

Encargado de Vuelo Cotización Solicitud aceptada Planificación 5 Producto 4 Procesamiento 6 Entrega final

(27)

27

Registro de datos del

vuelo

Encargado de

Vuelo

4 Procesamiento

Recopilación de datos del

vuelo

Encargado de

Procesamiento

Procesamiento de la

información

5-6 Producto final y

entrega Notificación al cliente

Encargado

Cotización

Entrega del producto

Encargado

Cotización

Tabla 2-1 Flujo de trabajo

2.1.1. Etapa Cotización (1)

El proceso comienza con la solicitud de una cotización por parte del cliente. Para ello el

encargado de armar la cotización espera archivos que provee el cliente geo-referenciales

denominados kmz o shapes que son la base para la cotización. Estos archivos representan las

figuras geométricas o áreas que deberán ser voladas para obtener el producto que desee el

cliente. Para ejemplificar se muestran dos archivos shapes y kmz visualizados con QGIS

Browser, herramienta que se instala con el paquete de base de datos geo-referenciales. En la

imagen 2-2 se puede apreciar cómo se podrían visualizar estos archivos.

Figura 2-2 Archivo shape o kmz

Continuando con el proceso teniendo en cuenta los archivos generados por el cliente, el

(28)

28

proximidad. De esta forma se generan nuevas versiones de los shapes y kmz que son

compartidos nuevamente con el cliente. Es importante recalcar que la cotización se realiza para

un conjunto de predios.

Como dijimos que una cotización puede tener un conjunto de predios luego de tener el conjunto

definidos se terminan de completar los datos de la cotización incluyendo el área total como

suma de las áreas de cada predio, la resolución, el costo del vuelo y demás datos.

El proceso de la revisión de los shapes y kmzs se repite hasta que se llega a un consenso y el

encargado de la cotización genera los datos específicos de la cotización en conjunto con los

valores económicos y se la envía al cliente. En este momento se puede mencionar que la

cotización entraría en un estado pendiente de aprobación por parte del cliente.

2.1.1.1. Hallazgos de cotización

Situación inicial Dificultad Impacto

Manejo de shapes

y kmz

Dificultad al localizar los

archivos Pérdida de tiempo

Problemas entre asociación de

archivos y cotización

Generación de

cotizaciones

incorrectas.

Registro de datos de cotización

de forma manual

Errores humanos.

Tiempo invertido en

tareas mecánicas.

Proceso de

aceptación de la

cotización

Se generan varias versiones de

archivos. Falta de control y no

se sabe cuál es la versión final.

Errores en el

proceso de trabajo.

Se pueden crear

cotizaciones con

archivos

(29)

29

Cálculo de costos

y margen

Falta de estandarización en el

cálculo, no hay un criterio ni

definido ni unificado de cálculo

No se conoce los

impuestos que se

deben pagar

descompensando el

equilibrio de

liquidez de la

empresa.

Solicitudes

enviadas

Falta de control sobre

solicitudes enviadas.

Falta de

seguimiento de los

clientes. Afecta

rentabilidad.

Tabla 2-2 Hallazgos cotización

2.1.2. Etapa Planificación (2)

Una vez aprobada la cotización las cotizaciones que están enviadas ya pueden ser planificadas.

Cabe recalcar que para el negocio de fotografía área la planificación consiste en tomar los datos

de la cotización del predio y asociarle datos técnicos específicos para ser tenidos en cuenta en

el vuelo. Para ello el encargado de la planificación visualiza los predios que debe planificar y

adjunta un archivo de extensión nca que tiene los datos más importantes para la planificación.

(30)

30

Figura 2-3 Ejemplo de nca

Con los datos que se listan a continuación, se obtiene el ancho y el largo de lo que cubre la

imagen. Para generar el rectángulo es /2 a partir del centro de foto.

 Image Width (Pixels)  Image Length (Pixels)  Image Width Ground (m)  Image Length Ground (m)

Con los datos que se listan a continuación, se generamos las líneas de vuelo. W=Coordenadas

Oeste, S= Coordenadas Sur. 1S Coordenadas de inicio de línea y número de línea. 1E

Coordenadas de final de línea y su número de línea

 W 33 50.274424 S 55 29.039079 W 1s

 W 33 42.893692 S 55 29.169030 W 1e

 W 33 42.908770 S 55 30.407469 W 2s

(31)

31

Tanto los datos del nca como los el archivo físico deben ser almacenados para su uso como se

coordenadas específicas para el vuelo, la resolución a aplicar, las cámaras utilizadas etc. Los

datos del archivo nca se toman como base para el vuelo y el archivo físico se guarda como registro de planificación.

2.1.2.1. Hallazgos de planificación

Situación

inicial Dificultad Impacto

Operación

archivos nca

manual

Almacenamiento y recuperación Errores humanos y pérdida de tiempo

Predios

pendientes de

planificar

Encargado de planificación no se

entera de los predios pendientes de

planificar

Demoras en el

proceso de trabajo.

Cotizaciones

pendientes de

planificar

No se sabe cuáles son las

cotizaciones pendientes de

planificar

Demoras en el

proceso de trabajo.

Inconsistencias.

Tabla 2-3 Hallazgos planificación

2.1.3. Etapa Vuelo (3)

En la fase de vuelo se toman las cámaras que realizan la obtención de las fotos y las filmaciones.

Luego se completa una planilla con la información el vuelo. Como referencia a continuación se

describen las diferentes tecnologías que intervienen en esta etapa:

 Cámaras digitales: Para la obtención directa de imágenes digitales métricas se utiliza como herramienta fundamental la Cámara Digital Fotogramétrica. La misma cuenta

con un sensor de imágenes electrónico que posibilita la obtención de dichas imágenes

en forma rápida y eficiente.

 Cámaras Analógicas: Para la realización de proyectos específicos se mantiene el empleo de la Cámara Analógica, la cual actúa apoyada por soportes tecnológicos de

(32)

32

 Flota de aviones: 2000 Aviation Systems cuenta con una flota propia de aeronaves, las que han sido modificadas especialmente para este tipo de trabajos.

 Sistemas de Navegación: Los vuelos fotogramétricos se realizan utilizando GPS de alta precisión asociado a programas de última tecnología.

2.1.4. Etapa Procesamiento (4)

El procesamiento de las fotos y filmaciones toma en cuenta lo solicitado por el cliente

recopilado en la cotización. En esta parte del proceso se obtiene las fotos y filmaciones

exactamente del área que requirió el cliente con el formato específico. Para el procesamiento

se utiliza software especializado llamado Enso Mosaic y Espa System.

2.1.5. Etapa Producto final y entrega (5 y 6)

El producto final se entrega a través del responsable de la cotización, notificando al usuario

final que el producto está listo. Luego el cliente se hace presente en la empresa y se realiza la

entrega en persona. A continuación se muestra algunos de los productos de 2000 Aviation

Systems:

(33)

33

El flujo se podría resumir con como muestra la siguiente imagen

Figura 2-5 Flujo

2.2. Tipo de usuarios y necesidades

Dentro del alcance del proyecto se identifican diferentes perfiles, usuarios finales y

administradores. Los primeros soportan los procesos operativos por ejemplo cotización y

planificación. Los segundos realizan actividades de administración de la herramienta como ser

mantenimiento de seguridad.

Los usuarios finales se componen de usuarios de cotización, planificación, vuelo y

(34)

34

En este proyecto se consideran las necesidades de los usuarios de cotización y planificación.

Para el caso del usuario de cotización tiene necesidad de:

 Enterarse cuando una cotización hace más de una semana que se envió pero que no ha

tenido respuesta por parte del cliente.

 Poder crear una nueva cotización creando la lista de campos que se cotizarán.

 Tener la posibilidad de poder generar un pdf con los datos de la cotización de forma

automática.

 Buscar información sobre las cotizaciones ya creadas mediante filtros.

Para el caso de los usuarios de planificación tienen necesidad de:

 Ver las cotizaciones que están listas para planificar.

 Poder realizar la planificación por predios.

 Asociar y recuperar archivos de planificación.

En el siguiente capítulo se detalla cómo se satisfacen las necesidades de los usuarios con una

visión del producto.

3. Enfoque de la solución

3.1. Objetivos generales del producto

El producto tiene por objetivo implantar una plataforma tecnológica que permita sustentar los

diferentes procesos operativos de 2000 Aviation Systems; cotización, planificación, vuelo y

procesamiento, logrando automatización, control y seguimiento de cada uno de los pasos del

ciclo de trabajo. El producto interviene de forma activa informatizando los procesos, superando

así la situación anterior logrando captar los datos mediante una interfaz amigable. La

información capturada se almacena de forma estructurada en una base de datos geoespacial

(35)

35

producto teniendo la posibilidad de recuperar los trabajos ya realizados de forma inmediata y

fácil de localizar entre otros beneficios.

3.2. Descripción funcional del producto

A continuación se muestra el sistema desde el punto de vista funcional como lo verán los

usuarios, describiendo las principales funcionalidades desarrolladas hasta el momento.

3.2.1. Página principal

Es el punto de entrada a las funcionalidades de la aplicación web, la cual será utilizada por los

usuarios que trabajen en la empresa.

En la misma se puede visualizar el logo de la empresa y un menú que permite la navegación a

los diferentes módulos del sistema.

(36)

36

3.2.2. Módulo de administración de las cotizaciones

3.2.2.1. Alta de cotización

Permite crear una nueva cotización en el sistema. La misma permite seleccionar entre otro

datos, el cliente a quien se le realiza la cotización, los productos a cotizar, agrupar los campos

donde será realizado el trabajo y el precio total a cotizar.

A continuación se muestran las pantallas correspondientes al flujo de alta de cotización.

Primero ingresamos a la página inicial de alta de cotización.

Figura 3-2 Pantalla inicial de alta de cotización

Luego de ingresar los datos de cliente, encargado y seleccionado los productos pasamos a crear

y asignar los grupos de campos. Para esto pulsamos el botón (nuevo) del pie de la grilla

(37)

37

Figura 3-3 Pantalla de alta de grupo de campo para el alta de cotización

En esta pantalla se ingresan los datos correspondientes a los campos a volar y fotografiar para

el trabajo cotizado. Entre ellos se encuentran la ubicación, el área, avión a utilizar, horas de

procesamiento y precio entre otros. Lego de ingresados los datos pulsamos aceptar,

(38)

38

Figura 3-4 Pantalla de alta de cotización conteniendo grupos de campos y datos

Cabe destacar que los valores de área total y precio son auto calculados por la aplicación. El

valor correspondiente al área total es una simple suma entre las áreas ingresadas en cada grupo

de campo, mientras que el precio total se calcula en base a los siguientes criterios:

Figura 3-5 Criterios utilizados para el cálculo del precio de la cotización

Luego ingresamos el método de pago y el tiempo estimado para la realización del trabajo y le

damos al botón “Aceptar”. Lo cual creará una nueva cotización en el sistema e informará al

usuario si desea adjuntar un archivo. Esto permite adjuntarle a la cotización un archivo de

(39)

39

fotografiar. El archivo podrá ser un archivo de tipo Shape o Kml/Kmz que el sistema procesa

para su posterior asociación.

Figura 3-6 Mensaje de aviso al usuario consultando si desea adjuntar un archivo.

Le damos que si y seleccionamos el archivo.

(40)

40

Luego de seleccionar el archivo y pulsar aceptar, el mismo se guarda en el sistema confirmando

la acción al usuario mediante un mensaje de confirmación.

Figura 3-8 Mensaje de aviso al usuario informando que el archivo fue subido correctamente.

A partir de este momento contamos con una nueva cotización en el sistema, la cual podrá ser

consultada mediante la funcionalidad de “Consulta Cotización”.

3.2.2.2. Consulta de cotización

Permite consultar las cotizaciones existentes en el sistema y funciona como punto de

entrada para las funcionalidades de edición de cotización, descarga de archivo

geoespacial y alta de planificación.

(41)

41

Como se puede observar en la pantalla anterior, la consulta de cotización puede realizarse

ingresando diferentes filtros de búsqueda. Los mismos son:

 Cliente, permite buscar las cotizaciones del cliente especificado

 Ubicación, busca las cotizaciones que tengan algún grupo campo en la ubicación

especificada.

 Campo, filtrará por las cotizaciones que tengan asociado algún grupo campo cuyo

nombre coincida con el ingresado en el filtro.

 Fecha desde, filtra todas las cotizaciones que fueron dadas de alta en una fecha

posterior a la ingresada en ésta filtro.

 Fecha hasta, filtra las cotizaciones dadas de alta con fecha anterior a la especificada en

éste filtro.

 Estado, retorna todas las cotizaciones con estado igual al ingresado.

Cabe destacar que los filtros de búsqueda son restrictivos o acumulativos, esto significa que

cada filtro ingresado por el usuario se utilizará para restringir la búsqueda de las cotizaciones

que cumplan con todos los criterios ingresados.

(42)

42

Figura 3-11 Resultado de búsqueda de Consulta de Cotización sin ningún filtro

Como se puede observar, la grilla de resultados presenta paginado ofreciendo al usuario

una mejor presentación de los resultados, pudiendo así navegar entre las distintas

páginas con la utilización de la barra de navegación.

Figura 3-12 Barra de navegación de las grillas

Además de la barra de navegación, puede observarse la presencia de los siguientes botones.

Figura 3-13 Botones de acciones en la grilla de búsqueda de cotizaciones

Estos botones permiten realizar acciones sobre las cotizaciones. Para su utilización se debe

(43)

43

Las acciones de los mismos son, editar la cotización seleccionada, agregar una planificación a

la cotización seleccionada y descargar el archivo geoespacial relacionado a la cotización

seleccionada respectivamente.

Cuando se selecciona una cotización, el sistema muestra debajo de la grilla de resultado de

búsqueda, otra grilla que contiene el detalle de los campos asociados a la cotización

seleccionada.

Figura 3-14 Detalle de los campos de la cotización seleccionada

3.2.2.3. Edición de cotización

Esta funcionalidad permite realizar las siguientes acciones:

 Editar una cotización ya existente en el sistema, pudiendo modificar tanto sus datos

como los datos referentes al archivo geoespacial adjunto.

 Enviar la cotización al cliente, lo cual modifica el estado de la cotización a estado

“Enviada” y la envía en formato PDF a la dirección de e-mail asociada al cliente. Un

(44)

44

 Descargar el archivo PDF correspondiente, esta funcionalidad permite la descarga de

la cotización realizada en formato PDF para su posterior impresión. Un emeplo de esto

se muestra en la Figura 3-16.

Figura 3-15 Ejemplo de e-mail al enviar la cotización

(45)

45

3.2.2.4. Descarga de archivo geoespacial

Permite descargar el archivo adjunto a la cotización en formato comprimido .zip. Esta

funcionalidad se accede desde la consulta de cotizaciones, seleccionando una cotización en la

grilla de resultados y pulsando el botón de descarga

Figura 3-17 Descarga de archivo geoespacial asociado a la cotización

3.2.3. Módulo de administración de planificaciones

3.2.3.1. Alta de planificación

Permite crear una nueva planificación asociándola a una cotización. Como se mencionó

anteriormente, para crear una planificación se deberá primero buscar las cotizaciones que estén

en estado “Enviada” en la pantalla de “Consulta Cotización” y pulsar el botón “Nueva

(46)

46

Figura 3-18 Pantalla inicial de alta de planificación.

Como se puede observar, la pantalla muestra los datos de la cotización a planificar y una grilla

donde se mostrarán las planificaciones asociadas a la cotización.

Al pulsar en el botón Nuevo del pie de la grilla de planificaciones, el sistema muestra la pantalla

de alta de planificación, donde se ingresarán los datos correspondientes.

Figura 3-19 Pantalla de ingreso de datos para el alta de planificación.

(47)

47

 Grupo de Campos, se seleccionan el grupo de campos a planificar. Los mismos

corresponden a los grupos ingresados en el alta de cotización.

 Encargado, responsable de la planificación.

 Tipo de Vuelo, se ingresa el tipo de vuelo a planificar.

 Archivo nca, permite adjuntar un archivo de tipo nca que será recuperado luego en el

módulo “Vuelo”.

 Archivo nma, igual al anterior pero no en todas las planificaciones se deberá ingresar.

Una vez ingresado los datos, presionamos el botón aceptar y la planificación se añade a la lista

de planificaciones para la cotización.

Figura 3-20 Pantalla de planificación conteniendo datos

3.2.3.2. Edición de planificación

Permite editar los datos de la planificación. Para ingresar a esta funcionalidad es necesario

seleccionar de la lista de “Planificaciones” aquella que se desee modificar y luego pulsar el botón “Editar”. Esto mostrará la pantalla correspondiente a la edición de planificación

(48)

48

3.2.3.3. Baja de planificación

Permite eliminar de la lista de planificaciones asociadas a la cotización, aquella planificación

que el usuario entienda correcto eliminar. Para ello es necesario seleccionar de la lista de

“Planificaciones” aquella que se desee eliminar y luego pulsar el botón “Borrar”. Esto, luego

de que el usuario confirme la acción, eliminará la planificación seleccionada de la lista.

3.3. Beneficios de la solución

La solución brindada a 2000 Aviation Systems consiste no solo en la definición e

implementación de un producto tecnológico sino también se realizó un trabajo de revisión de

los procesos actuales como parte de la ingeniería de requerimientos.

Son múltiples los casos en los cuales la revisión de procesos implicó una mejora para el negocio

por citar algunos, la determinación de los costos de la cotización y el valor final se realizaba de

forma tentativa sin un proceso ordenado, probado y recurrente. Esto implica una mejora

respecto a la situación actual permitiendo no solo ajustar los valores de acuerdo a la necesidad

de la empresa sino también permite tener más controlado las variables económicas del negocio

así como también poder realizar mayor análisis de información.

La identificación de procesos manuales que consumían un esfuerzo considerable por parte de

los usuarios y su análisis para la automatización fue otra mejora que se identificaron. A modo

de ejemplo, para generar la cotización se creaba un pdf con la información de la cotización, con

el producto se genera de forma automática.

El seguimiento de las solicitudes de trabajos muchas veces quedaban en el olvido, con el sistema

los filtros ayudan a identificar rápidamente cuales son aquellas que están pendientes, cuando se

crearon y a que cliente se las envió para tener un seguimiento eficaz de los trabajos. El sistema

permite que el usuario de cotizaciones obtenga rápidamente los datos del cliente al cual se

cotizó para contactarlo.

La manipulación de archivos que existe tanto en la cotización como en la planificación genera

(49)

49

puede rápidamente perder el control. El sistema permite almacenar los archivos físicos luego

de haber realizado las transformaciones correspondientes manteniendo el orden de los procesos

y ofreciendo a través de una interfaz amigable la posibilidad de recuperar los archivos de forma

(50)

50

4. Ciclo de vida y metodología

4.1. Ciclo de vida

Consideramos que un ciclo de vida debe permitir aplicar las diferentes actividades de desarrollo

de software en su sentido más amplio de forma eficiente. En este sentido fuimos conociendo

que el proyecto presentaba un conjunto de características que deberían de tenerse en cuenta para

la elección del ciclo de vida.

Como se explicó en el capítulo 2 - Planteo del problema, al inicio del proyecto identificamos

que por parte del cliente había una indefinición de sus procesos, o carencia para transmitirnos

cómo era su forma de trabajo, y eso, sumado a que ninguno de los integrantes del equipo contaba

con el vocabulario y términos tan específicos del negocio de filmación y fotografía área, nos

significó pensar el tener que dedicar una etapa inicial para comprender el negocio, y lo que se

pretendía del sistema a desarrollar.

De esta manera comprender ciertas características del cliente, características del contexto de la

organización, y como nosotros como grupo no teníamos conocimientos previos de este negocio,

nos ayudaría a entender cómo podrían ser las características del producto.

A medida que íbamos entendiendo sus procesos, identificamos que había un desafío

tecnológico, lo cual fue otra variable tenida en cuenta al momento de seleccionar el ciclo de

vida

En conclusión decidimos aplicar un ciclo de vida iterativo e incremental, debido a que es el que

más se ajusta a nuestra situación de no tener todos los requerimientos definidos en principio.

Con dicho ciclo de vida se especifican la mayoría de los requerimientos inicialmente, en la

primera etapa de análisis y luego se va construyendo en base a los incrementos, y se puede ir

modificando o incorporando algún requerimiento de acuerdo a lo que el cliente nos va

(51)

51

4.2. Metodología

Para seleccionar la metodología que íbamos a utilizar en el proyecto nos basamos tanto en las

características del cliente, como lo que pretendíamos nosotros como equipo y en el ciclo de

vida seleccionado.

Características del cliente:

Desde el primer momento nos manifestó interés y compromiso para que el proyecto saliera

adelante estando siempre a nuestra disposición a la hora de plantear reuniones de relevamiento

y al contactarlo por alguna duda que nos surgía, explicándonos detalladamente todos sus

procesos para nosotros entender su negocio.

Tanto es así que nos designaron un recurso exclusivo que ofició de punto de contacto entre la

empresa y nosotros, por ser quien tenía completo conocimiento del negocio y nos marcaba los

requerimientos del sistema.

Características del equipo:

Es un equipo de 3 integrantes, lo cual facilita la comunicación entre los mismos, todos

coincidíamos en la preferencia de trabajar presencial en grupo. Gracias a nuestras experiencias

laborales nos hace ser un equipo que se complementa ya que tenemos distintas fortalezas

tecnológicas. Queríamos a su vez ser un equipo auto-gestionado, donde las decisiones

importantes se tomaran en común y estábamos dispuestos a ser abiertos respecto a los cambios

que el cliente nos solicitara, ya que nuestro acuerdo con ellos fue el de desarrollarles un

producto que le generara valor a su negocio, por sobre todas las cosas.

Además, queríamos tener una documentación liviana para estar más enfocados al conocimiento

del negocio.

Ciclo de vida:

Iterativo e incremental, como mencionamos anteriormente en este capítulo.

Una vez que tuvimos claras las condiciones en las que nos encontrábamos, comenzamos a

evaluar las exigencias tanto de la metodología ágil como la tradicional para poder decidir cuál

(52)

52

De esta manera fue que descubrimos que cumplíamos con la mayoría de los principios del

manifiesto ágil como ser:

 Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y

continua de software de valor.

 Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo.

 Entregar con frecuencia software que funcione, en periodos de un par de semanas

hasta un par de meses, con preferencia en los periodos breves.

 Las personas del negocio y los desarrolladores deben trabajar juntos de forma

cotidiana a través del proyecto.

 Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y

el respaldo que necesitan y procurándoles confianza para que realicen la tarea

 La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de

un equipo de desarrollo es mediante la conversación cara a cara.

 El software que funciona es la principal medida del progreso

Sin embargo decidimos incluir ciertas acciones que tienden más a la planificación y

documentación para el proceso de analizar y evaluar los riesgos, y para el proceso de mantener

la calidad durante todo el proyecto, ya que encontrábamos beneficioso el hecho de tener un plan

para seguir, y estas acciones tienden más a ser parte de una metodología tradicional.

En conclusión, la metodología elegida para nuestro proyecto es una metodología hibrida entre

ágil y tradicional.

En el contexto de una metodología con características ágiles, decidimos que para la gestión se

utilizará Scrum adaptado a nuestra realidad, la cual está detallada en el capítulo 10 - Gestión.

(53)

53

5. Ingeniería de requerimientos

5.1. Justificación de la metodología de relevamiento

Como se detalla en el capítulo 10, sección 10.5.1 - Etapas del proyecto, el sprint 0 fue uno de

los principales en cuanto a definición y relevamiento. A su vez como se especificó en el capítulo

4 Ciclo de vida y metodología, la estrategia de relevamiento fue realizada dentro de un ciclo

incremental dividido por iteraciones donde en el sprint 0 se realizaron las principales

actividades de relevamiento.

Es necesario recalcar que dado que los requerimientos del cliente no los tenían del todo claros,

el dominio del problema complejo, los integrantes del equipo no tenían experiencia en un tipo

de negocio tan específico y que el cliente tampoco tenía mucha experiencia en ciclos de

desarrollos, es que se definió una fuerte etapa de relevamiento en la etapa inicial del proyecto

orientada a comprender el dominio del problema, es decir, comprender el negocio, sus

principales requerimientos y necesidades, características de funcionamiento, complejidades y

prioridades.

De esta instancia surgieron entre otros el product backlog priorizado, las user stories para el

sprint 1, los insumos para la definición de los requerimientos no funcionales y por lo tanto para

la definición de la arquitectura.

Una vez obtenidas las principales definiciones del sistema, en los sprints plannings se tomaban

las epics/themes y mediante entrevistas y reuniones se bajaban los requerimientos a un nivel de

mayor detalle llegando hasta la user story con sus criterios de aceptación. Teniendo en cuenta

que utilizamos una metodología híbrida con componentes ágiles dentro de un ciclo de vida

incremental dividido en 4 sprints creemos que abordar los requerimientos de forma progresiva,

dada las características del cliente y el proyecto en sí, eran más eficientes que realizar en una

solo etapa el relevamiento y especificación de todos los requerimientos del sistema.

El relevamiento progresivo en un ciclo de vida incremental iterativo usando una metodología

ágil permite que el cliente vaya teniendo una noción más definida de qué es lo que quiere a