Gestión de Conformidad de Obras

Universidad ORT Uruguay

Facultad de Ingeniería

Gestión de Conformidad

de Obras

Entregado como requisito para la obtención del título de Ingeniero de

Sistemas

Fernando Fructos - 102261

Gonzalo Villar - 143125

Agustín Sarasua - 152756

Tutor: Marcelo Cagnani

2

Declaración de autoría

Nosotros, Fernando Fructos, Gonzalo Villar y Agustín Sarasua, declaramos que el trabajo que se presenta en esta obra es de nuestra propia mano.

Podemos asegurar que:

 La obra fue producida en su totalidad mientras realizábamos el proyecto de grado de la carrera Ingeniería en Sistemas.

 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.

Montevideo, 3 de marzo de 2016

Fernando Fructos Gonzalo Villar

3

Agradecimientos

Durante este proceso intenso, por demás interesante y lleno de retos el grupo tuvo la colaboración de un conjunto de personas a las que queremos agradecer especialmente:

A nuestro tutor Marcelo Cagnani, quien durante todo el año estuvo cerca en todo momento, guiándonos y aportando visión y experiencia sin la cual nos hubiera sido imposible llegar a buen puerto.

A nuestros tres revisores, Álvaro Ortas, Amalia Alvares y Leonardo Scafarelli, por haber llevado el proyecto a otro nivel con sus opiniones, críticas y sugerencias.

Al personal de BuildingLink, Ben Millspaugh, Peter Kasindorf, Tim Jessup, Josh Langdon y James Trent y muy especialmente a Jerry Kestenbaum, quien nos brindó la posibilidad de construir y aportar en un proyecto innovador en una de las locaciones más importantes del mundo.

A la Universidad ORT y a su equipo docente en su totalidad, quienes nos han formado como profesionales y como personas.

Finalmente, a nuestras familias sin cuyo apoyo y comprensión no hubiéramos podido realizar este trabajo.

4

Abstract

El objetivo de este proyecto consiste en desarrollar un sistema que permita organizar, gestionar y orquestar el proceso de aprobación y gestión de conformidad de trabajos de obra en edificios entre las diferentes partes que participan, incluyendo: aseguradoras, propietarios, inquilinos y proveedores entre otros.

Se entiende por Gestión de Conformidad a la solicitud, reunión, revisión y aprobación de documentación de distinta índole, con el fin de asegurar que se cumple con los requisitos para la realización de una determinada obra o trabajo en un edificio.

La necesidad surge por parte de la empresa BuildingLink (http://www.buildinglink.com), radicada en Nueva York, Estados Unidos que se especializa en brindar soluciones de administración y gestión de operaciones de edificios. Su conocimiento del mercado, su relacionamiento con compañías administradoras de edificios y los servicios que brindan actualmente a través de su plataforma BuildingLink lo colocan en una buena posición para que el software sea adoptado como un estándar de mercado.

Actualmente este tipo de gestión es realizada manualmente, sin un software específico de soporte lo que hace al proceso ineficiente, generando trabajo extra, clientes insatisfechos y en algunos casos, multas y problemas legales.

Como parte del proyecto, se desarrolla un sistema que automatiza gran parte del proceso de revisión, aprobación y seguimiento de trabajos y contratistas siguiendo los lineamientos establecidos por el cliente.

El desafío más importante que presenta el proyecto se centra en cambiar el proceso actual, incluyendo todas las partes involucradas en el mismo, facilitando el trabajo y mejorando la calidad de la información disponible para todas las partes.

Se utilizó una adaptación de Scrum como marco para gestionar el desarrollo y relevamiento del mismo.

5

Índice

1.1 ACERCA DE ORTSOFTWARE FACTORY ... 15

1.2 ACERCA DEL CLIENTE ... 15

1.3 ACERCA DEL EQUIPO ... 16

1.4 MOTIVACIÓN ... 17

1.5 TERMINOLOGÍA ... 17

1.6 ESTRUCTURA DEL DOCUMENTO ... 17

2. DESCRIPCIÓN DEL PROYECTO ...19

2.1 INTRODUCCIÓN ... 19

2.2 DESCRIPCIÓN GENERAL Y SELECCIÓN. ... 19

2.2.1 Una gran oportunidad ... 19

2.3 OBJETIVOS DEL PROYECTO ... 20

3. DESCRIPCIÓN DEL PROCESO ...21

3.1 INTRODUCCIÓN ... 21

3.2 DEFINICIONES ... 21

3.3 CONSIDERACIONES PARA LA DEFINICIÓN DEL PROCESO ... 22

3.4 PROCESO DISEÑADO ... 23 3.4.1 Fase Inicial ... 23 3.4.2 Fase de Construcción ... 25 3.4.3 Fase Final ... 27 3.5 ROLES ... 28 4. INGENIERÍA DE REQUERIMIENTOS ...29 4.1 INTRODUCCIÓN ... 29

4.2 ALCANCE DEL SISTEMA ... 29

4.2.1 Situación Actual... 29

4.2.2 Objetivos de la nueva solución. ... 31

4.2.3 Principales funcionalidades del sistema ... 33

4.2.4 Actores del sistema ... 36

4.2.5 Modelo Conceptual ... 37 4.3 EXTRACCIÓN Y ANÁLISIS ... 38 4.3.1 Primera etapa ... 38 4.3.2 Segunda etapa ... 38 4.3.3 Herramientas ... 40 4.4 ESPECIFICACIÓN ... 40 4.4.1 Prototipos ... 40 4.4.2 Product Backlog ... 43

4.5 ESTIMACIÓN DE LAS HISTORIAS ... 44

4.6 VALIDACIÓN ... 45

5. ARQUITECTURA ...46

6

5.2 ATRIBUTOS DE CALIDAD Y REQUERIMIENTOS NO FUNCIONALES ... 46

5.2.1 Usabilidad ... 46 5.2.2 Disponibilidad y confiabilidad ... 48 5.2.3 Performance ... 51 5.2.4 Modificabilidad... 56 5.2.5 Compatibilidad... 57 5.2.6 Seguridad ... 57 5.3 SELECCIÓN DE LA TECNOLOGÍA ... 58

5.3.1 Aplicación de Frontend (Sitio Web) ... 58

5.3.2 Aplicación de Backend (Server) ... 60

5.3.3 Bases de datos... 60

5.3.4 Software y Herramientas Base ... 60

5.4 VISTAS ARQUITECTÓNICAS ... 61

5.4.1 Introducción ... 61

5.4.2 Vista de módulos ... 61

5.4.3 Vista de componentes y conectores... 67

5.4.4 Vista de despliegue ... 68

5.5 PATRONES ARQUITECTÓNICOS ... 71

5.5.1 Patrón Model View Controller (MVC) ... 71

5.5.2 Patrón de Capas Lógicas (Layered Pattern) ... 71

5.5.3 Patrón de Capas Físicas (Multi-tier Pattern) ... 71

5.5.4 Patrón Cliente Servidor (Client - Server Pattern)... 72

5.6 VALIDACIÓN DE LA ARQUITECTURA ... 72 5.6.1 Refactoreo ... 72 6. GESTIÓN DE LA CALIDAD ...73 6.1 INTRODUCCIÓN ... 73 6.2 ASPECTOS ORGANIZACIONALES ... 73 6.3 ACTIVIDADES DE SQA ... 74 6.3.1 Investigación ... 74 6.3.2 SQA y metodología ... 74 6.3.3 Estándares ... 75 6.3.4 Validación ... 76 6.3.5 Verificación y Revisión. ... 76 6.3.6 Pruebas ... 77 6.3.7 Revisiones Académicas ... 80

7. GESTIÓN DEL PROYECTO ...81

7.1 INTRODUCCIÓN ... 81

7.2 TIMELINE DEL PROYECTO ... 82

7.3 OBJETIVOS DE LOS SPRINTS ... 83

7.4 RELEASE BURNDOWN CHART ... 84

7.5 MÉTRICAS ... 85

7.5.1 Esfuerzo Estimado vs Esfuerzo Completado ... 85

7.5.2 Story Points Comprometidos vs Story Points Completados ... 86

7.5.3 Bug Severidad por Sprint ... 88

8. GESTIÓN DE RIESGOS ...89 8.1 INTRODUCCIÓN ... 89 8.2 IDENTIFICACIÓN DE RIESGOS ... 89 8.3 RIESGOS DETECTADOS ... 91 8.4 EVOLUCIÓN ... 94 8.4.1 Tecnologías Involucradas ... 94

8.4.2 Locación del Cliente ... 95

7 8.4.4 Funcionalidad Incorrecta ... 97 9. GESTIÓN DE LA CONFIGURACIÓN ...99 9.1 INTRODUCCIÓN ... 99 9.2 ROLES Y RESPONSABILIDADES ... 99 9.3 REPOSITORIOS ... 99

9.3.1 Elementos de configuración del software ... 99

9.3.2 Versionado del código fuente ... 100

9.3.3 Estructura del repositorio ... 100

9.4 VERSIONADO DE LA DOCUMENTACIÓN ... 101

9.4.1 Estructura del repositorio ... 102

9.4.2 Esquema de permisos ... 102

9.5 PROCESO DE GESTIÓN DE LA CONFIGURACIÓN ... 103

9.5.1 Sistema de control de cambios ... 103

10. GESTIÓN DE LA COMUNICACIÓN ... 105

10.1 INTRODUCCIÓN ... 105

10.2 HERRAMIENTAS Y CANALES DE COMUNICACIÓN ... 105

10.3 INCONVENIENTES ... 105

11. CONCLUSIONES ... 107

11.1 CONCLUSIONES GENERALES ... 107

11.2 LECCIONES APRENDIDAS ... 107

12. REFERENCIAS BIBLIOGRÁFICAS ... 109

ANEXO – PLAN DE CALIDAD ... 110

1. Definiciones ... 111

2. Metodología de trabajo ... 112

3. Plan de la Calidad ... 113

ANEXO – ENTREGABLE ARQUITECTURA... 115

ANEXO - EJEMPLO DE REQUISITOS DOCUMENTALES POR CATEGORÍA DE TRABAJO ... 121

ANEXO – INFORME DE REVISIÓN PRESENCIAL CON EL CLIENTE ... 125

ANEXO – SEGUIMIENTO DE RIESGOS ... 128

ANÁLISIS INICIAL DE RIESGOS ... 128

SPRINT 1 ... 129 SPRINT 2 ... 131 SPRINT 3 ... 132 SPRINT 4 ... 133 SPRINT 5 ... 134 SPRINT 6 ... 135 SPRINT 7 ... 136 SPRINT 8 ... 137 SPRINT 9 ... 138 SPRINT 10 ... 139 SPRINT 11 ... 140 SPRINT 12 ... 141

8

ANEXO - SPRINT BACKLOGS ... 163

SPRINT 1BACKLOG ... 163 SPRINT 2BACKLOG ... 166 SPRINT 3BACKLOG ... 169 SPRINT 4BACKLOG ... 173 SPRINT 5BACKLOG ... 178 SPRINT 6BACKLOG ... 183 SPRINT 7BACKLOG ... 190 SPRINT 8BACKLOG ... 197 SPRINT 9BACKLOG ... 201 SPRINT 10BACKLOG ... 206 SPRINT 11BACKLOG ... 210 SPRINT 12BACKLOG ... 212

ANEXO – CASOS DE PRUEBA ... 218

SPRINT 5 ... 218 SPRINT 6 ... 220 SPRINT 7 ... 222 SPRINT 8 ... 224 SPRINT 9 ... 226 SPRINT 11 ... 229 SPRINT 12 ... 230

ANEXO – BUGS REPORTADOS POR EL CLIENTE ... 231

ANEXO – SPRINT RETROSPECTIVES ... 233

ANEXO - CARTA DE COMPROMISO DEL CLIENTE ... 235

ANEXO – ENCUESTA DE SATISFACCIÓN DEL CLIENTE ... 236

ANEXO – FOTO DE RELEASE REVIEW EN NUEVA YORK ... 237

9

Índice de Tablas

Tabla 3-1: Roles y responsables definidos. ... 28

Tabla 5-1: Resoluciones por dispositivo. ... 47

Tabla 6-1: Estándares utilizados. ... 75

Tabla 6-2: Estandares en C# ... 75

Tabla 6-3: Herramientas utilizadas para las pruebas. ... 77

Tabla 6-4: Herramientas utilizadas para las pruebas. ... 80

Tabla 8-1: Escala de Impacto ... 89

Tabla 8-2: Escala de Probabilidad ... 90

Tabla 8-3: Magnitud del Riesgo. ... 90

Tabla 8-4: Magnitud del Riesgo. ... 92

10

Índice de Figuras

Figura 3-1: Fase tareas de inicial. ... 23

Figura 3-2: Proceso Fase de Construcción. ... 25

Figura 3-3: Proceso Fase Final ... 27

Figura 4-1: Situación Actual ... 30

Figura 4-2: Proceso a desarrollar. ... 32

Figura 4-3: Estados de un documento. ... 35

Figura 4-4: Modelo Conceptual ... 37

Figura 4-5: Esfuerzo en horas/Sprint... 39

Figura 4-6: Prototipo en proceso. Se pueden ver los comentarios del cliente en los pequeños íconos amarillos ... 41

Figura 4-7: Prototipo terminado ... 42

Figura 5-1: Ejemplo de autocomplete... 48

Figura 5-2: FailoverTraffic Routing Method ... 49

Figura 5-3: Configuración Azure ... 50

Figura 5-4: Características de Instancia ... 52

Figura 5-5: Configuración del balanceador de carga ... 55

Figura 5-6: Modulos a realizar ... 56

Figura 5-7: Diagrama de paquetes ... 62

Figura 5-8: Patrón Repository ... 63

Figura 5-9: Capas Lógicas ... 65

Figura 5-10: Diagrama de Componentes ... 67

Figura 5-11: Diagrama de Despliegue... 69

Figura 6-1: Proporción de esfuerzo en tareas de desarrollo y testing ... 78

Figura 6-2: Comparación - Testing y Retrabajo ... 79

Figura 7-1: Timeline del proyecto. ... 82

Figura 7-2: Release Burnout Chart ... 84

Figura 7-3: Esfuerzo Estimado vs Esfuerzo Completado ... 85

Figura 7-4: Story Points Comprometidos vs Story Points Completados ... 86

Figura 7-5: Velocidad / Sprint ... 87

Figura 7-6: Bug Severidad / Sprint ... 88

Figura 8-1: Riesgos - Tecnologías Involucradas ... 94

Figura 8-2: Riesgos - Locacion del Cliente ... 95

Figura 8-3: Riesgos - Disponibilidad del equipo ... 96

Figura 8-4: Funcionalidad Incorrecta ... 97

Figura 9-1: Estructura de directorios TFS. ... 101

Figura 9-2: Estructura de directorios Google Drive. ... 102

11

Glosario

A

AngularJS: Framework JavaScript basado en MVC (Modelo-Vista-Controlador) y que se

centra en intentar dinamizar documentos HTML, DHTML (Dynamic HTML) y ejecutarse como aplicación de una sola página.

API: Acrónimo de Application Programming Interface. Conjunto de subrutinas, funciones

y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.

B

Brainstorming: en español, lluvia de ideas o también conocida como tormenta de ideas,

es una herramienta de trabajo grupal que facilita el surgimiento de nuevas ideas sobre un tema o problema determinado.

Browser: Navegador de Internet.

Bug: Error o fallo en un programa de computadora o sistema de software que

desencadena un resultado indeseado.

Burndown Chart: Métrica de Scrum que permite observar el desempeño de un equipo

durante una iteración.

C

Cloud Computing: Paradigma que permite ofrecer servicios de computación a través

de una red, que usualmente es Internet.

CEO: Acrónimo de “Chief Executive Officer” COI: Acrónimo de “Certificate Of Insurance”

E

Epic: Registro de tarea o historia a realizar dentro del Product Backlog que es

12 F

Feedback: Comentarios y sugerencias devueltas por un usuario sobre un tema

evaluado.

G

GIT: Sistema gratis y open source de control de versión distribuida.

Google Drive: Servicio de alojamiento de archivos que fue introducido por Google el 24

de abril de 2012.

H

HTML: Acrónimo de “HyperText Markup Language”. Lenguaje interpretado por

navegadores de internet utilizado para la construcción de sitios web en general.

M

Moqups: Herramienta colaborativa que permite crear SVG mockups y wireframes. Mockup: Prototipo de interfaz de usuario utilizado para el relevamiento de

requerimientos.

N

.NET: Framework de Microsoft que hace un énfasis en la transparencia de redes, con

independencia de plataforma de hardware y que permita un rápido desarrollo de aplicaciones.

O

OAuth2: Protocolo que permite flujos simples de autorización para sitios web o

aplicaciones informáticas.

OCR: Acrónimo de Optical Character Recognition (Reconocimiento Óptico de Caracteres).

ORTsf: Software Factory de la Universidad ORT Uruguay.

Open Source: Término utilizado generalmente para indicar la propiedad de un producto

13 P

Planning Poker: Método de estimación consensuado entre integrantes de un equipo. Product Backlog: Lista ordenada del trabajo a realizar para crear, mantener y sostener

un producto. A cargo del Product Owner.

R

Release Review: Reunión llevada a cabo luego de realizado un release, con el fin de

mostrar lo construido hasta el momento.

REST: Acrónimo de “Representational State Transfer”. Estilo de arquitectura.

Actualmente se refiere a cualquier interfaz entre sistemas que utilice HTTP para obtener datos o ejecutar operaciones sobre estos datos.

RNF: Acrónimo de “Requerimientos No Funcionales.”

S

Scrum: 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.

SCM: Acrónimo de “Software Configuration Manager”. Gestión de la Configuración del

Sofware.

SCMer: Rol encargado de la gestión de configuración del software.

SPA: Acrónimo de “Single Page Application”. Aplicación web construida sobre una única

página HTML que es actualizada dinámicamente según las interacciones con el usuario.

Sprint: Iteración de duración fija.

Sprint Backlog: Artefacto utilizado para el registro de tareas a realizar en una iteración

en la metodología Scrum.

Sprint Retrospective: Evento de 3 horas o menos, realizado al y para terminar un Sprint.

Le sirve al equipo de Scrum para evaluar el Sprint pasado y planear mejoras a ser implementadas en el próximo Sprint.

SQA: Acrónimo de “Software Quality Assurance”.

SQAer: Rol encargado del aseguramiento de la calidad del software.

SQL: Acrónimo de “Structured Query Language” es un lenguaje declarativo de acceso a

14

Story Point: Medida arbitraria utilizada en la metodología Scrum.

T

Timeline: Representacion grafica del paso del tiempo y los sucesos asociados al periodo

y universo referido.

Trello: Herramienta online para manejar proyectos y tareas personales.

TFS: (Team Foundation Server): Producto de Microsoft que provee manejo de código

fuente (vía Team Foundation Version Control o Git), reportes, manejo de requerimientos, project management (para proyectos agiles o en casada), builds automáticos, testing y manejo de releases.

V

Visual Studio Online: Herramienta de Microsoft que ofrece diversos servicios para la gestión de equipos de desarrollo de software.

W

Web API: Plataforma para construir servicios HTTP accesibles por un amplio rango de clientes, incluyendo exploradores y terminales móviles.

Windows Azure: Plataforma general que tiene diferentes servicios para aplicaciones,

desde servicios que alojan aplicaciones en alguno de los centros de procesamiento de datos de Microsoft para que se ejecute sobre su infraestructura (Cloud Computing) hasta servicios de comunicación segura y federación entre aplicaciones.

15

1. INTRODUCCIÓN

En el presente documento se describe el proyecto académico titulado “Gestión de Conformidad de Obras”, requisito para la obtención del título de grado de la carrera de Ingeniería en Sistemas de la Universidad ORT Uruguay. El mismo fue realizado bajo la tutoría del laboratorio de ORT Software Factory para el cliente BuildingLink cuyas oficinas se encuentran ubicadas en New York, Estados Unidos.

1.1 Acerca de ORT Software Factory

“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.

ORTsf está abocado fundamentalmente a desarrollar en los estudiantes las habilidades que un profesional de las Tecnologías de la Información debe dominar y aplicar.

Esto se logra a través de un método de enseñanza diseñado para que estudiantes de fin de carrera, apoyados por tutores especializados, trabajen en equipos con proyectos reales y aplicando prácticas avanzadas de Ingeniería de Software.” [1]

1.2 Acerca del Cliente

Sitio web: http://www.buildinglink.com/

Situada en Nueva York, BuildingLink es una empresa dedicada al desarrollo de una suite de productos para la gestión de edificios residenciales. La empresa brinda una plataforma web compuesta de múltiples portales para la gestión administrativa y operativa de edificios buscando mejorar la experiencia tanto de residentes como de administradores de propiedades. Actualmente su producto es utilizado en más de 3000 propiedades en EEUU y en el mundo.

La empresa posee un equipo propio de desarrolladores y agentes capaces de dar soporte, añadir o modificar funcionalidades y desarrollar nuevos productos.

El equipo del presente proyecto ha mantenido contacto directo durante el desarrollo del mismo con el CEO de la empresa, Jerry Kestenbaum, quien fuera el principal impulsor de la idea a desarrollar y el principal contacto en el transcurso del proyecto.

Se destaca también la participación de un experto de dominio, Tim Jessup. Por su experiencia pasada en trabajos relacionadas al área de conformidad de obras, Tim fue un referente en los momentos de relevar requerimientos brindando toda su experiencia en el área.

16 La contraparte técnica en el cliente fue Ben Millspaugh, Arquitecto de Software de BuildingLink y quien lidera los esfuerzos de desarrollo en la empresa.

1.3 Acerca del Equipo

El equipo se encuentra compuesto por tres estudiantes de la carrera de Ingeniería en Sistemas y el tutor del proyecto. A continuación, se describen los perfiles de cada miembro:

Agustín Sarasua

Estudiante avanzado de la carrera de Ing. en Sistemas, actualmente trabajando como Desarrollador Senior en Despegar.com. Posee un perfil de desarrollador web y experiencia en el stack de Java.

Fernando Fructos

Estudiante avanzado de la carrera de Ing. en Sistemas, posee más de 9 años de experiencia en desarrollo de software con un perfil en aplicaciones web empresariales y recientemente aplicaciones para dispositivos móviles. Actualmente forma parte de la empresa DevFront como socio.

Gonzalo Villar

Estudiante avanzado de la carrera de Ing. en Sistemas, posee más de 8 años de experiencia en desarrollo de aplicaciones empresariales, web y de escritorio, así como también aplicaciones para dispositivos móviles. Actualmente forma parte de la empresa DevFront como socio.

Marcelo Cagnani

Tutor del proyecto, Licenciado, MBA y PMP, ha liderado proyectos de implementación de TI en instituciones financieras, sector público y empresas comerciales. Con más de 12 años de trabajo en proyectos de gobernanza de TI actualmente se desempeña como Gerente Senior de Consultoría de TI en la empresa KPMG.

17

1.4 Motivación

Al momento de tener que decidir el proyecto a realizarse, el equipo evaluó diversas opciones, desde ideas que iban surgiendo dentro del equipo hasta proyectos ofrecidos en la feria de proyectos de la Universidad.

Dentro de las ideas evaluadas surge la de realizar un producto innovador que agregue valor a la solución que ofrece actualmente BuildingLink (actual cliente y con el cual dos miembros del equipo poseen relación laboral de 6 años) y que a su vez presente un desafío desde el punto de vista tecnológico y de procesos.

Parte de la motivación de realizar este proyecto surge también del hecho de trabajar con un cliente residente en el extranjero con todos los desafíos que ello conlleva.

1.5 Terminología

A lo largo del documento se emplearán indistintamente los términos “obra” y “trabajo” para referirse a actividades realizadas por un contratista o por el propio residente que requieran la presentación de documentación para su realización. Ejemplos: mudanzas, reformas, fumigaciones.

Se procedió idénticamente con los términos “Mockup” y “Prototipo”.

1.6 Estructura del documento

A continuación, se presenta una breve descripción de los principales capítulos del documento.

Glosario - Se define la terminología usada en el documento.

Descripción del proyecto - Se realiza una descripción del proyecto incluyendo objetivos

y alcance del mismo, metodología de trabajo y se realiza una introducción al proceso utilizado durante la ejecución del proyecto.

Descripción del proceso - Se describe el proceso de ingeniería de software

implementado en el proyecto.

Ingeniería de requerimientos - Se describe el proceso de ingeniería de requerimientos,

indicando la metodología utilizada. También se incluye un resumen de los requisitos del sistema desarrollado.

Arquitectura - Se muestra el diseño arquitectónico elaborado para la solución y se

justifican las principales decisiones de diseño tomadas. Además, se describen los problemas a los que se enfrentó el equipo y las soluciones encontradas.

18

Gestión de la calidad - Se describen las distintas actividades realizadas para el

aseguramiento de la calidad durante el transcurso del proyecto, enfocadas tanto en el producto como en el proceso.

Gestión del proyecto - Se incluye un resumen general del proyecto dividido según las

distintas áreas de gestión.

Gestión de riesgos – Se describe en detalle la identificación, análisis, cuantificación y

gestión de los riesgos relacionados con el proyecto.

Gestión de la configuración - Se describen los distintos aspectos de la configuración

del sistema, entre los que se encuentran el proceso de control de cambios, gestión de repositorios y otras actividades del rol SCM.

Gestión de la comunicación – Se describen los canales y procedimientos establecidos

para la comunicación entre los actores del proyecto.

Conclusiones - Se extraen conclusiones de los datos recolectados durante el proyecto

y se elabora un compendio de lecciones aprendidas.

Bibliografía - Se listan las fuentes y recursos a los cuales accedieron los integrantes del

proyecto en el transcurso del mismo.

Anexos - Se incluyen documentos relevantes para complementar la información

19

2. DESCRIPCIÓN DEL PROYECTO

2.1 Introducción

En el presente capítulo se brinda información general del proyecto. En particular, se incluye una descripción general del proyecto, los objetivos del mismo y una síntesis del alcance del sistema.

2.2 Descripción general y selección.

Actualmente dos miembros del equipo del proyecto tienen relación laboral con el cliente por lo cual se le planteó al mismo la realización de un proyecto en conjunto. La idea del producto fue presentada por el cliente en términos generales brindando los principales requerimientos debido a su conocimiento del mercado y su constante motivación por innovar. El equipo luego se interiorizó en el problema, se evaluó su viabilidad y se concretó la realización del mismo en el marco del proyecto de fin de carrera de Universidad ORT.

“Gestión de Conformidad de Obras” es un proyecto de desarrollo de software cuyo objetivo es la construcción de un sistema para la gestión de documentación y seguimiento del proceso de aprobación y revisión de obras o actividades dentro de un edificio.

Dichas obras/actividades requieren documentación de distinta índole, incluyendo cobertura de seguro, planos, recibos y licencias entre otros.

2.2.1

Como se mencionó anteriormente, el cliente posee un producto ampliamente difundido y establecido en Nueva York y varias ciudades de Estados Unidos, lo cual le brinda un amplio conocimiento del mercado de la gestión de edificios y sus necesidades.

Se nos presenta entonces la oportunidad de desarrollar una solución de alto valor para una empresa que posee un canal de distribución y una base de clientes inmejorable para impulsar un sistema de este tipo y establecerlo como un referente del mercado en Nueva York.

20

2.3 Objetivos del proyecto

El objetivo del proyecto a nivel del producto es construir una herramienta accesible tanto en plataforma web como en dispositivos móviles que redefina, agilice y simplifique las actividades del proceso de aprobación de obras y actividades a realizarse dentro de un edificio.

Dentro de estas actividades se encuentran la digitalización, revisión y aprobación de documentos y proveedores llevada a cabo tanto por los residentes como por personal de administración, miembros de la comisión, técnicos (arquitectos, ingenieros civiles) o corredores de seguro.

Se plantea a nivel de cronograma liberar una versión beta del sistema ejecutando en el ambiente de producción acordado con el cliente (Windows Azure).

Así mismo se plantearon objetivos a nivel del equipo, que se enuncian a continuación:  Desarrollar un producto profesional.

 Cumplir con las expectativas del cliente.

 Aplicar los conocimientos adquiridos a lo largo de la carrera

o Diseñar y aplicar un proceso de construcción de software siguiendo un cronograma real.

o Llevar a cabo tareas de ingeniería de requerimientos.

o Diseñar e implementar una arquitectura de software que cumpla con los requerimientos no funcionales relevados.

o Aplicar las buenas prácticas de diseño aprendidas.

 Asignar roles y ejecutar correctamente las tareas asociadas a los mismos.  Obtener la aprobación y recibir la titulación.

21

3. DESCRIPCIÓN DEL PROCESO

3.1 Introducción

El equipo definió un proceso propio donde se definieron actividades, ceremonias y ciclo de vida entre otros. Se trata de una adaptación del marco de trabajo que plantea la metodología Scrum, el cual según la evaluación realizada por el equipo es la que mejor se adaptaba al cliente, al equipo y a las necesidades del proyecto.

En este capítulo describiremos el proceso en detalle, cómo el equipo se adaptó al mismo y los cambios realizados a lo largo del ciclo de vida.

3.2 Definiciones

Al comenzar el proyecto el equipo definió los aspectos relacionados al proceso de ingeniería y a la forma de trabajo con la cual se llevaría adelante.

En la etapa de definición se elaboraron documentos para establecer las pautas sobre las distintas áreas del proceso de ingeniería y sobre el ciclo de vida del proyecto.

Dichas definiciones incluyen:  Ciclo de vida del proyecto  Proceso de construcción  Metodología de construcción

 Reuniones de grupo semanales, algunas presenciales y otras con comunicaciones a distancia.

 Dedicación necesaria (que después sería ajustada)

 Roles, que dado el tamaño pequeño del grupo terminaron siendo cumplidos por más de un integrante

 Plan de comunicación con el cliente

 Actividades de aseguramiento de la calidad  Hitos del proyecto

22

3.3 Consideraciones para la definición del proceso

El proceso se definió teniendo en cuenta las siguientes limitantes y características tanto del cliente como del grupo:

 Experiencia de los miembros del equipo con diferentes formas de trabajo. o Todos los miembros del equipo se desempeñan actualmente empleando

Scrum como metodología.

 Preferencia del cliente por la utilización de prototipos descartables.

o Dada la relación laboral de los integrantes del equipo con el cliente, se sabía de antemano la preferencia por el uso de prototipos descartables como método para la extracción de requerimientos.

 Cliente comprometido con el proyecto y disponible a pesar de la distancia.

o El cliente ha manifestado un gran interés en el proyecto y habitualmente está disponible en la comunicación laboral diaria por lo que se espera una comunicación fluida.

 Requerimientos poco definidos previamente.

o Al tratarse de una aplicación innovadora en el área, gran parte de las funcionalidades no están claras – a pesar de contar con un experto de dominio - por lo que deberá haber una etapa inicial de relevamiento exhaustivo de requerimientos.

 Dedicación horaria de los integrantes del grupo limitada.

o Al hecho del reducido número de integrantes del equipo se suma que todos se desempeñan en trabajos de dedicación full-time por lo que se deberá tener en cuenta una limitada dedicación horaria.

 Conocimiento personal y laboral previo entre todos los integrantes.

o Los integrantes del equipo poseen relación a través de la universidad y también han tenido relación laboral.

23  Nivel de conocimiento de los integrantes del equipo con las tecnologías

involucradas.

o Se emplearán tecnologías, herramientas y frameworks con las que algunos miembros del equipo no poseen experiencia por lo que se debe considerar una curva de aprendizaje y un posible riesgo tecnológico.

3.4 Proceso diseñado

Luego de evaluar los puntos mencionados anteriormente se diseñó éste proceso en el que podemos identificar tres fases divididas claramente que describiremos a continuación.

3.4.1

24 Esta primera fase del proyecto se realizó para definir los aspectos de planificación, de metodología, identificar los riesgos y realizar un relevamiento importante de la funcionalidad involucrada y esperada por el cliente.

Las tareas no presentan grandes dependencias entre sí y fueron realizadas en paralelo.

Definición Product Backlog Inicial

Esta actividad consiste en un relevamiento inicial de todo el sistema con el fin de conseguir un panorama cercano del alcance del proyecto.

En esta actividad se trabajó en contacto continuo con el cliente mediante el intercambio constante de emails, reuniones vía Skype y telefónicas.

El resultado de esta actividad fue una primera versión del Product Backlog conteniendo la mayoría de las épicas e historias a desarrollarse priorizadas.

Identificación de Riesgos y Planificación

Se realizó una evaluación de los riesgos asociados al proyecto, tanto de construcción de la solución como del entorno.

De esta actividad se obtiene un plan de gestión de riesgos con todos los riesgos considerados y evaluados, así como también los distintos planes de mitigación.

Planificación de la Calidad

La planificación de la calidad consistió en definir un plan de calidad con las actividades a realizarse a lo largo del proyecto para asegurar que se construyera la solución deseada, satisfaciendo las necesidades del cliente.

Se definieron actividades de control y revisión de distintos aspectos del proyecto, estándares de codificación, entre otras cosas. El plan de calidad en detalle se puede ver en el Anexo – Plan de Calidad.

Gestión de la Configuración

Esta actividad involucró la definición del plan de gestión de la configuración donde se identificaron los elementos de configuración a versionar, se evaluaron y establecieron las distintas herramientas de versionado a utilizar y repositorios necesarios.

25

Gestión de la Comunicación

En esta actividad se definió como iba a ser la comunicación con el cliente y dentro del equipo. La misma consistió en la definición de los medios y herramientas de comunicación además de la definición de reuniones a realizar a lo largo del proyecto junto con la periodicidad de las mismas.

3.4.2

Figura 3-2: Proceso Fase de Construcción.

Esta fase del proceso fue la diseñada para la construcción del software. Posee su base en la metodología ágil SCRUM, con la cual los miembros del equipo poseen experiencia, pero no es una aplicación estricta de dicha metodología.

La entrada en esta etapa se da una vez culminada la elaboración de los distintos planes y resultados de análisis relacionados al proyecto, como ser el Plan de Calidad, la

26 identificación y evaluación de riesgos con sus respectivos planes de mitigación, y la gestión de la configuración y comunicación.

Se definieron iteraciones de duración fija de dos semanas dado la naturaleza cambiante de los requerimientos que inicialmente no estaban del todo definidos.

Planificación de Liberaciones

Actividad definida para planificar las liberaciones del sistema en un ambiente controlado (Release Planning). Sobre dichas liberaciones el cliente realizó de pruebas de aceptación y validación de las funcionalidades desarrolladas en cada una.

Planificación de Sprint

Esta actividad del proceso de construcción consiste en la selección de las historias del Product Backlog a desarrollarse en la iteración a realizar teniendo en cuenta la priorización de estas historias realizadas en conjunto con el cliente (actividad que está asociada directamente con la planificación de las liberaciones realizada). Como resultado de esta actividad obtenemos el Sprint Backlog, artefacto que contiene las tareas a realizar en dicho Sprint.

Construcción

Esta actividad consiste en la realización de las tareas del Sprint Backlog resultante de la actividad anterior. Se definió una reunión semanal presencial (weekly meeting) entre los miembros del equipo durante el transcurso de cada iteración para chequear el avance y discutir problemas o posibles desviaciones en las estimaciones, así como también nuevas tareas que debían ser tenidas en cuenta. Como resultado de esta actividad se obtiene un incremento del producto.

Retrospectiva del Sprint

Esta ceremonia tomada de Scrum (Sprint Retrospective) se realiza de forma presencial con todos los miembros del equipo al finalizar la iteración con el objetivo de analizar los resultados obtenidos. Los resultados son analizados mediante la extracción de métricas y mediante un análisis del proceso.

En esta ceremonia se discuten aspectos relacionados al proceso que el equipo considera que debe mejorar y los planes de acción para mejorar dichos aspectos. También se exponen los puntos buenos del proceso y buenas prácticas realizadas.

27 Se discuten también nuevos riesgos que puedan haber aparecido en el proyecto o riesgos que se materializaron en la iteración.

3.4.3

Figura 3-3: Proceso Fase Final

La fase final del proceso comprende la liberación del software a un ambiente de pruebas simulando el contexto real de operación del mismo, con el fin de que el cliente realice una prueba completa del mismo.

Se planearon en primera instancia 2 liberaciones de este tipo para pruebas de aceptación con el cliente y pruebas completas del sistema.

Despliegue en ambiente de controlado

Esta etapa comprende la instalación del software en un ambiente que imita el ambiente de producción con el fin de realizar las pruebas necesarias. Se configura el software adecuadamente y se realizan pruebas de sistema y de stress.

Revisión de Release

Etapa en la que se muestra el producto al cliente, demostrando las funcionalidades desarrolladas y la forma de utilizarlas.

28

Pruebas de validación y aceptación

Esta etapa depende del cliente y consiste en una prueba total del software con el fin de detectar fallas y/o desviaciones en los requerimientos. De esta actividad surgen defectos encontrados por el cliente y/o no conformidades que deberán ser solucionadas. Se emplea una planilla de cálculo con un formato predeterminado para organizar la tarea de registro. Ver Anexo – Bugs Reportados por el Cliente

Planificación de Sprint

Luego de registrada la información en la etapa anterior, se vuelve a realizar una etapa de planificación de Sprint donde se analizan las tareas a realizar para corregir las incidencias reportadas y cambios que el cliente solicite.

3.5 Roles

Según el proceso definido, se cuenta con una lista de roles definidos durante el transcurso del proyecto. Los roles definidos se asignaron de la siguiente forma:

Rol Responsable

Ingeniero de Requerimientos Equipo

Arquitecto Gonzalo Villar, Agustín Sarasúa

SQAer Fernando Fructos

SCMer Gonzalo Villar

Desarrollador Equipo

Tester Equipo

Scrum Master Agustín Sarasúa

Product Owner Gonzalo Villar

29

4. INGENIERÍA DE REQUERIMIENTOS

4.1 Introducción

El presente capítulo tiene como intención brindar información detallada referente al proceso de ingeniería de requerimientos realizado a lo largo del proyecto. Se detallarán las actividades de extracción, análisis, especificación y validación realizadas en el relevamiento de los requerimientos funcionales y no funcionales.

4.2 Alcance del sistema

4.2.1

Actualmente en el estado de New York, E.E.U.U. para llevar a cabo una obra de ampliación, reparación o entrada/salida de residentes en un apartamento en un edificio, es necesario reunir determinada documentación que posteriormente debe ser validada y aprobada. Esta documentación es requisito indispensable e ineludible y previene al interesado de hacer cualquier avance.

¿Qué complejidades presenta esto?

 Requerimientos/Documentos necesarios no están siempre claros y varían en gran magnitud dependiendo del tipo de obra. Esto presenta una problemática tanto para quien los debe presentar como para quien los debe validar.

 El seguimiento, control y validación de estos requerimientos se realiza de forma manual consumiendo tiempo de personal de administración sin generar valor.  El acceso y manejo de los documentos también es manual, lo que contribuye a la

ineficiencia del proceso.

 Es engorroso realizar el seguimiento a las diferentes obras y llevar control de, por ejemplo, los vencimientos de los distintos documentos y los plazos que se han establecidos para comienzo y fin de obra.

30

Diagrama de Proceso Actual

31

4.2.2

El principal objetivo de la solución es mejorar la comunicación entre las partes involucradas en el proceso de aprobación de trabajos en un edificio.

Si bien no se elimina la necesidad de contar con la documentación real, lo que se busca es brindar una herramienta que:

 Ahorre tiempos de ida y vuelta de documentación entre las partes involucradas de un proceso.

 Mejore la organización de la documentación requerida para cada tipo de obra. (dado que las mismas van a estar precargadas en el sistema).

 Mejore y organice la comunicación y registro de las etapas por las que pasa un pedido de trabajo.

 Permita crear una base de datos de proveedores con el objetivo futuro de usarla en otros modelos de negocio.

 Disminuya o evite las consecuencias legales y económicas relacionadas a los vencimientos de determinados documentos.

32

Proceso a Desarrollar

33

4.2.3

A continuación, se detallan las principales funciones que cumple el sistema según lo solicitado por el cliente. La descripción detallada de todo el sistema se puede encontrar en el Product Backlog. (Ver Anexo – Product Backlog)

Administración de requisitos documentales

Los requisitos documentales para la realización de trabajos, desde la renovación completa de un apartamento hasta algo tan simple como ingresar un bien (por ejemplo, un sofá), varían no solo dependiendo de la tarea sino también dependiendo de la compañía que administre el edificio.

El sistema permitirá configurar para cada edificio y para cada tipo de tarea (categoría) los requisitos documentales necesarios para llevarla a cabo, centralizando el acceso a esta información, haciéndola accesible en todo momento a todos los involucrados y por lo tanto agilizando todo el proceso y haciéndolo menos proclive a errores y confusiones. Los tipos de requerimientos relevados hasta el momento son:

 Certificados de cobertura de seguros (COI)  Declaración de trabajo

 Planos

 Permisos municipales

 Permiso de trabajo de proveedores  Gastos diversos (ej.: Médicos)  Informe de progreso

Un ejemplo de la configuración de la categoría y sus requisitos puede ser encontrado en el Anexo - Ejemplo de Requisitos Documentales por Categoría de Trabajo.

Solicitudes de trabajo

Un interesado en que se realice un trabajo en un apartamento (Residente o integrante de la administración del edificio) podrá dar inicio al proceso de aprobación de dicho trabajo ingresándolo en el sistema.

Dicha acción da inicio al proceso descripto en la figura 4-2:

 La solicitud debe ser revisada y categorizada correctamente, dependiendo del trabajo a realizase, por un actor designado para tal tarea. Esta categorización determinara el conjunto de requisitos a cumplir.

 Esta solicitud es luego revisada y aprobada por la comisión del edificio. Si bien los elementos de decisión son ajenos al sistema, estos incluyen: fechas de comienzo y fin de trabajo, tipo de trabajo, reglas específicas del edificio, etc.

34  Los responsables de aportar la documentación son notificados, permitiendo el acceso al sistema de dos maneras: como invitados o como usuarios registrados.

 Una vez aportados estos documentos, son revisados y aprobados por usuarios de la administración designados para esta tarea.

 El trabajo puede comenzar luego de que toda la documentación requerida haya sido aprobada.

Administración de proveedores

Las empresas e individuos que lleven a cabo los trabajos serán ingresados en el sistema, formando una base de datos que permitirá entre otras cosas acortar los procesos en futuras participaciones, recibir una calificación por parte de los usuarios y generar un flujo de trabajo que permitirá en el futuro aportarle valor a BuildingLink a través de un modelo de negocio con membresías.

Subida de documentos

El sistema no reemplaza el uso de documentación en papel. El propósito es agilizar el proceso permitiendo que los responsables de aportar la documentación puedan subir al sistema una versión digital que estará disponible para todos los involucrados con los privilegios necesarios.

Revisión y aprobación de documentos

Esta versión digital será revisada y aprobada por un usuario designado por la administración o por la comisión. Luego se procede a la recolección de las versiones en papel de los documentos.

35 Figura 4-3: Estados de un documento.

Alertas

Gran parte del beneficio de manejar este proceso con un sistema informatizado consiste en la posibilidad de programar alertas automáticas ante eventos como ingreso de nuevas solicitudes, vencimientos de documentos, finales de trabajo, necesidad de aprobación de un documento, facilitando la tarea de la administración al evitar con esas alertas consecuencias indeseadas como multas, demoras o acciones legales.

Cabe aclarar que el mal uso del sistema no hace responsable a BuildingLink de ninguna consecuencia generada por tal uso.

36

Valoración de proveedores

Los residentes podrán evaluar y comentar sobre los proveedores ingresados al sistema que han participado en sus trabajos, creando comunidad y agregando valor a la aplicación.

Integración con productos de BuildingLink

La aplicación se integrará con BuildingLink para compartir datos de edificios, usuarios, unidades e información existente en un módulo en los sistemas de BuildingLink llamado “Alterations” que solamente permite registrar fechas de comienzo y fin de obras.

OCR sobre documentación

Realizando OCR sobre los documentos subidos se obtendrán metadatos que permitirán hacer búsquedas a los usuarios.

Interacción entre residentes y administración

Se permitirá la comunicación entre la administración, los residentes y los responsables de aportar documentación para enriquecer y complementar la interacción requerida en los distintos estados de las solicitudes.

4.2.4

Se identificaron los siguientes actores del sistema:

Solicitador: Capaz de crear una solicitud. Puede ser un residente o un administrador en

beneficio de un residente o del edificio.

Definidor de Alcance: Capaz de categorizar las solicitudes. Aprobador de Trabajo: Capaz de revisar y aprobar una solicitud.

Administrador: Configura el sistema. Monitorea solicitudes de un edificio.

Agentes externos: Técnicos (Arquitectos, Ingenieros), corredores de seguros. Suben

37

4.2.5

38

4.3 Extracción y Análisis

Las actividades de extracción y análisis fueron realizadas en dos etapas, una primera etapa de relevamiento de las funcionalidades en alto nivel (Epics) donde fue concebido el Product Backlog inicial y una segunda etapa, gestionada con Scrum, donde fueron relevadas y detalladas éstas funcionalidades.

4.3.1

Esta primera etapa fue realizada al comienzo del proyecto donde se realizó la primera versión del Product Backlog conteniendo las épicas más importantes a desarrollar priorizadas. La priorización de las épicas fue realizada en conjunto con el cliente teniendo en cuenta tanto la importancia como las dependencias existentes entre ellas.

El relevamiento de estas primeras funcionalidades se realizó utilizando las siguientes técnicas y métodos:

1. Diagramas de actividad de los procesos principales presentes en el sistema,

éstos son el proceso de aprobación de trabajos de obras y de proveedores.

2. Reuniones con el cliente y el experto de negocio Tim Jessup vía Skype. 3. Intercambio de emails.

Esta etapa fue realizada en conjunto con otras actividades, entre ellas, la definición del proceso a utilizar, por lo que la misma no fue gestionada utilizando la metodología definida (Scrum).

Además del relevamiento realizado, se estableció con el cliente el mecanismo de realización de prototipos descartables para el relevamiento detallado de las historias y pantallas a desarrollar.

4.3.2

Partiendo de la base del Product Backlog, resultado del relevamiento realizado en la primera etapa, pasamos a esta segunda etapa de relevamiento donde nos enfocamos en especificar más a fondo las Épicas (requerimientos funcionales y no funcionales) relevados en la primera etapa.

Se hizo una primera versión del Product Backlog detallando las historias en alto nivel más importantes y requeridas (Epics) las cuales fueron priorizadas por el cliente. Luego

39 de priorizar dichas Epics y ver la dependencia entre las mismas se comenzó la parte de prototipado de las historias de mayor prioridad.

Las historias de relevamiento y prototipación se realizaron a lo largo de todo el ciclo de vida del proyecto. Los primeros Sprints realizados tuvieron mayor dedicación para la realización y validación de los prototipos de las historias y funcionalidades de mayor prioridad y que teníamos mejor relevadas. Por este motivo podemos decir que se realizó una primera fase de fuerte prototipación compuesta por los primeros Sprints realizados.

Figura 4-5: Esfuerzo en horas/Sprint

Como podemos ver, en los primeros cuatro Sprints hay un mayor esfuerzo dedicado a tareas de relevamientos de requerimientos (Línea Azul).

Luego aumenta el esfuerzo dedicado a otras tareas, por ejemplo, de desarrollo (Línea Roja). Si bien el esfuerzo dedicado a tareas de prototipado disminuye, no desaparece, dado que el relevamiento y definición de requerimientos continuó a lo largo de la construcción del producto.

40 Como mencionamos anteriormente, el relevamiento de requerimientos se realizó mediante la técnica de construcción de prototipos descartables utilizando una herramienta colaborativa online donde el cliente realizaba comentarios y validaba los mismos. Además de esta herramienta, se realizaron diagramas de actividad de los procesos más importantes del negocio.

4.3.3

Diagramado colaborativo: Lucid Chart es una herramienta que nos permite realizar diagramas online de forma colaborativa. Tiene una limitación en la versión gratis la cual permite utilizar solo 60 objetos en los diagramas por lo que el equipo decidió comprar una suscripción anual paga. [2]

Mockups descartables: Moqups [3] es una herramienta que nos permite realizar mocks de pantallas (interfaz de usuario), soporta múltiples usuarios editando al mismo tiempo y el agregado de comentarios sobre las pantallas desarrolladas. La versión gratis tiene pocos objetos (widgets) por lo que decidimos comprar una suscripción anual para acceder a más objetos.

4.4 Especificación

La especificación de requerimientos se realizó a través del prototipado y del Product Backlog (artefacto de Scrum) utilizando una planilla de Google Docs construida a partir de un template de la misma herramienta.

4.4.1

A continuación, se muestra un ejemplo de los prototipos realizados con el feedback del cliente, los cuales fueron utilizados para orientar el desarrollo y validar lo construido.

41 Figura 4-6: Prototipo en proceso. Se pueden ver los comentarios del cliente en los pequeños íconos amarillos

42 Figura 4-7: Prototipo terminado

43

4.4.2

En un principio, comenzamos utilizando la herramienta de Microsoft Visual Studio Online para realizar la gestión de Scrum y armar el Product Backlog, pero al momento de querer armar gráficos y obtener métricas, la misma no se adecuaba a nuestras necesidades ya que para ciertos gráficos (simples) y métricas era necesario integrar la herramienta con Reporting Services, el cual es un servicio pago. Por este motivo y teniendo en cuenta el tamaño del equipo y la complejidad de la herramienta, fue que decidimos migrar el Product Backlog y los Sprint Backlog realizados hasta el momento a una planilla de Google Docs.

El Product Backlog contiene las historias ordenadas por prioridad donde la historia que aparece primera en la lista es de mayor prioridad que las que le siguen.

Se utilizó el template estándar recomendado por Scrum para describir las historias de desarrollo:

“Como <tipo de usuario>, quiero <objetivo> de manera tal que <razón o motivo>.”

A su vez, cada historia contiene las condiciones de aceptación relevadas y acordadas con el cliente las cuales fueron necesarias para la posterior validación y formulación de los casos de pruebas a realizar sobre la misma.

La siguiente tabla muestra una historia del Product Backlog a modo de ejemplo.

Sprint ID Backlog ID Descripción de Tarea Criterios de aceptación Tipo de Tarea Status SP Estimados 5 5 ID5-5 Como residente/inquilino quiero poder ver un resumen de mis pedidos de trabajo y trabajos en la página principal

Debe de mostrarse estado de los pedidos de trabajo y porcentaje de completitud de los trabajos en progreso. El dashboard debe ser responsivo para que se vea bien desde múltiples plataformas.

DEV DONE 13

Tabla 4-1: Ejemplo de Historia

Como podemos ver en la tabla anterior, además de la descripción y las condiciones de aceptación, en el Product Backlog también se categorizan las historias por tipo (Desarrollo, Prototipado, etc.), este campo es utilizado con el único propósito de extraer

44 métricas. También cada historia tiene un campo para describir el estado actual de la misma (TODO, IN PROGRESS y DONE) y la estimación en Story Points de la historia. El Product Backlog puede encontrarse en el Anexo – Product Backlog.

Una vez priorizadas y seleccionadas las historias a desarrollar para un Sprint, armamos el Sprint Backlog el cual contiene todas las tareas (tasks) a realizar para completar con las historias. En la siguiente tabla se muestra el desglose de tareas de una de las historias del backlog, en este caso la historia con ID5-5.

Es importante mencionar que por un tema de facilidad y rapidez al momento de utilizar la planilla, decidimos utilizar el formato ID”S”-”T” para identificar las historias, donde “S” indica el Sprint y “T” el número de historia. Para el ejemplo anterior se trata de la historia 5 del Sprint 5 y las siguiente son todas tareas pertenecientes a la misma:

5 5 ID5-5

Desarrollo Front Dashboard

Resident DEV Agustín Agustín DONE 8

5 5 ID5-5

Desarrollo Backend Dashboard

Resident DEV Gonzalo Gonzalo DONE 4

5 5 ID5-5

Pruebas unitarias Dashboard

Resident DEV Gonzalo Gonzalo DONE 1

5 5 ID5-5

Pruebas funcionales Dashboard

Resident SQA Gonzalo Gonzalo DONE 1

Tabla 4-2: Ejemplo de Numeración

Cada tarea, además de tener su descripción correspondiente tiene una categorización utilizada al igual que en el Product Backlog para la extracción de métricas. También se especifica quien originó la tarea y el responsable de ejecutarla, el estado de la tarea y la estimación en horas de la misma.

Los Sprints Backlog pueden encontrarse en Anexo - Sprint Backlogs

4.5 Estimación de las historias

La estimación de las historias del Product Backlog se realizó utilizando la técnica de Planning Poker. Una vez seleccionada la historia a estimar, cada integrante del equipo debía asignarle a la tarea un tamaño utilizando la escala de Fibonacci (1, 2, 3, 5, 8, 13 y 21) y en caso de que la estimación de alguno de los integrantes sea muy distinta a la de los otros, se discutía entre el equipo.

45

4.6 Validación

La actividad de validación se realizó sobre los prototipos y sobre los diagramas de actividad de los procesos de negocio. Si repasamos en el Product Backlog alguna de las historias de creación de prototipo, podemos ver que las tareas desglosadas de dicha historia se componen de una tarea de desarrollo del prototipo y una de validación con el cliente del mismo.

La siguiente tabla muestra un ejemplo de esto.

4 1 ID4-1

Desarrollo Prototipo Vista/Edición de

Trabajo – Manager PRO Agustin Agustin DONE 3

4 1 ID4-1

Validación Prototipo Vista/Edición

de Trabajo – Manager SQA Agustin Agustin DONE 1

46

5. ARQUITECTURA

5.1 Introducción

El presente capítulo tiene como intención brindar información técnica detallada referente a la arquitectura de los sistemas a desarrollar. Se describirán las decisiones y tácticas de diseño utilizadas en los mismos con el fin de cumplir con las restricciones, requerimientos no funcionales y atributos de calidad establecidos por el cliente.

También se describirán tanto las tecnologías utilizadas para el desarrollo como las características del ambiente donde será desplegada la solución.

En conjunto con el código fuente, se le entregó al cliente documentación referente a la arquitectura del sistema (ver Anexo – Entregable Arquitectura), donde se muestran las distintas vistas de arquitectura y diagramas principales.

5.2 Atributos de calidad y requerimientos no funcionales

A continuación, se detallan los principales atributos de calidad, requerimientos no funcionales y restricciones comprendidas en la arquitectura del sistema.

5.2.1

La usabilidad del sistema se presenta como uno de los atributos de calidad de mayor prioridad para el cliente ya que se ha acostumbrado a los usuarios de BuildingLink a productos con un alto grado de usabilidad. Tanto la disposición de los elementos web dentro de los sitios como los mensajes mostrados a los usuarios, los títulos, las instrucciones y los textos de los botones y links deben ser previamente aprobados por el cliente mediante la utilización de mockups.

47 A continuación, se listan los requerimientos no funcionales relevados referentes a la usabilidad del sistema.

Nombre: RNF1 - Usabilidad - Sitios Responsivos

Descripción: Como usuario del sistema quiero poder acceder a todas las

funcionalidades del mismo desde cualquier dispositivo y que se vea correctamente de forma intuitiva. Se establecerán tres umbrales de resolución donde la pantalla deberá acomodarse de manera tal que se vea correctamente sin necesidad de hacer scroll horizontal.

En el siguiente cuadro se detallan los umbrales de resolución de dispositivos definidos:

Resolución <= 479px 479px < Resolución < 768px Resolución >= 768px

Teléfonos móviles en

general Tablets/IPads en general

Desktops/Laptops en general

Tabla 5-1: Resoluciones por dispositivo.

Para estos umbrales, las páginas de los portales del residente y del administrador deben visualizarse correctamente chequeando que las opciones del menú se re-acomodan y que el contenido de la página se ajusta a la pantalla sin necesidad de realizar scroll horizontal.

Nombre: RNF2 - Usabilidad - Facilidad de Uso del Sistema

Descripción: Como un usuario nuevo del sistema quiero poder aprender fácilmente las

funcionalidades que el mismo tiene disponible. Esto hace referencia a cómo el usuario mediante uso de botones/pagina de ayuda, link a help desk y preguntas frecuentes entre otros, es capaz de utilizar satisfactoriamente estas funcionalidades.

Todos los botones de ayuda, tooltips de ayuda, links y demás serán especificados en los mockups y cada mockup es validado previamente con el cliente.

48

Nombre: RNF3 - Usabilidad - Asistencia del sistema al usuario / facilidad de uso.

Descripción: Como usuario del sistema quiero que el mismo me ayude en el llenado de

los datos conocidos. Esto hace referencia a inputs de datos que el usuario realiza en una página y que el sistema puede autocompletar utilizando datos de la base datos. Ejemplo: al filtrar una categoría de trabajo en un combo, si el usuario comienza a escribir los caracteres "Flo", el sistema debería sugerirle la opción "Florist" automáticamente.

Todos los campos de texto autocompletables serán expresados y validados en cada mockup y conformarán parte de los criterios de aceptación indicados por el cliente. A modo ilustrativo, la siguiente figura ilustra un ejemplo de autocomplete.

Figura 5-1: Ejemplo de autocomplete

5.2.2

A continuación, se describen tanto los requerimientos no funcionales referentes a la disponibilidad y confiabilidad del sistema como las tácticas de diseño tomadas para cubrir dichos requerimientos. Todos los requerimientos referentes a la disponibilidad del sistema fueron aprobados por el arquitecto de sistemas perteneciente al equipo del cliente.

Nombre: RNF4 - Disponibilidad y Confiabilidad - High Availability, Failover

Descripción: Se requiere una alta disponibilidad del sistema, el sistema debe ser

tolerante a fallas, una falla en el sistema no debe dejar al mismo fuera de servicio. Los datos no pueden quedar inconsistentes ante una falla.

49 A continuación, se detallan las tácticas de diseño empleadas para cotejar éste atributo de calidad.

 Failover Traffic Routing Method

Se desplegarán en múltiples instancias la misma aplicación. Todo el tráfico de la aplicación será procesado por una sola instancia (principal) y en caso de ocurrir una falla, otra instancia de la aplicación (secundaria) será quien atienda el tráfico de la misma dejando en un estado no disponible a la instancia que ha fallado. Esta instancia de la aplicación seguirá atendiendo el tráfico de la aplicación hasta que la instancia principal se encuentre disponible nuevamente.

La siguiente figura ilustra cómo funciona el mecanismo mencionado.

Figura 5-2: FailoverTraffic Routing Method

El usuario realiza un pedido (request) a la aplicación que se encuentra desplegada en varios nodos (instancias). El servicio de "Microsoft Azure Traffic Manager" [4], utilizado para redireccionar el tráfico entrante a una aplicación (load balancer), obtiene de una tabla que contiene un listado de las instancias que tienen desplegada la aplicación, la instancia que está atendiendo los pedidos y envía el pedido (request) a la misma.

50 En nuestro caso, el sistema será desplegado en dos instancias iguales ubicadas en dos datacenter distintos de Windows Azure, uno ubicado en el oeste y el este de Estados Unidos respectivamente. Ésta decisión se debe a que el sistema, en principio va a estar disponible para usuarios ubicados físicamente en Nueva York. Por este motivo, la instancia principal estará ejecutando en el data center ubicado en el Este de Estados Unidos ya que geográficamente estará más cerca al lugar donde accederán los usuarios. La instancia secundaria, que estará atendiendo pedidos del sistema sólo en caso de que la instancia principal quede fuera de servicio, estará desplegada en el data center ubicado en el Oeste de Estados Unidos.

La siguiente figura muestra la configuración en Windows Azure de dichas instancias.

51  Transaccionalidad, Rollback

Todas las modificaciones sobre los datos cumplirán con las propiedades ACID [5] (Atomicidad, Consistencia, Aislamiento y Durabilidad) de forma tal que ante una falla no quedarán inconsistencias sobre los datos. Ante una falla debe aplicarse un Rollback sobre la transacción en curso. Se usará la base de datos transaccional SQL Server de Windows Azure para este motivo.

5.2.3

A continuación, se detallan los requerimientos no funcionales y restricciones relevados con el cliente referentes a la Performance de los sistemas a desarrollar. También se describen las tácticas de diseño tomadas para cubrir dichos requerimientos, así como también escenarios específicos para probarlos.

Nombre: RNF5 - Performance - Tiempos de respuesta

Descripción: Se requiere que el sistema no demore más de 5 segundos en terminar con

el procesamiento de una tarea y darle una respuesta al cliente. Queda por fuera tiempos insumidos por otros sistemas (Integración con otros sistemas). Se espera probar que las consultas realizadas a la base de datos sean performantes y no influyan negativamente en la experiencia de usuario.

A continuación, se detallan las tácticas de diseño empleadas para cumplir con éste atributo de calidad.

 Aumento de recursos

Windows Azure nos permite escalar dinámicamente en recursos de la aplicación, pudiendo así aumentar la capacidad de procesamiento lo cual mejoraría la performance. Ésta tarea puede ser configurada para que se realice de forma automática por Windows Azure tomando en cuenta el nivel de procesamiento de los recursos contratados o también de manera manual. Se acordó con el cliente que en una primera etapa se desplegará la solución en un ambiente controlado de forma manualmente y una vez que tengamos más datos sobre el comportamiento y la evolución de la aplicación, evaluar configurar la misma para que escale forma automática en caso de ser necesario.

52 La siguiente imagen muestra las características de la instancia seleccionada y las opciones disponibles para aumentar los recursos de la aplicación.

Figura 5-4: Características de Instancia

Para la primera salida a producción, se va a ejecutar la aplicación en una instancia de tamaño Small (1 Core con 1,75 GM de memoria RAM).

Para medir la performance de la aplicación, se realizaron pruebas de carga (stress) sobre las páginas que muestran los dashboard de los administradores y los residentes, las cuales serían dentro de la aplicación las que realizan mayor cantidad de consultas sobre la base de datos y también las que serán las más accedidas dentro de las aplicaciones.

Se realizaron escenarios simulando distintos niveles de carga que se describen a continuación: