sistema m´ovil para la gesti´on de vehıculos

INTRODUCCION PLANIFICACION ANALISIS DISENO IMPLEMENTACION PRUEBAS Calidad Conclusiones Bibliografıa

Sistema movil para la gestion de vehıculos

David Borrego GutierrezManuel Palomo Duarte

Lorena Gutierrez Madronal

22 de febrero de 2015


INDICE IINTRODUCCION

PLANIFICACION

Metodologıa de desarrolloOrganizacionEstimacion de tiemposEstimacion de costes

ANALISIS

Analisis funcionalRequisitos no funcionales

DISENO

Diseno fısicoDiseno logico

IMPLEMENTACION

InfraestructuraServidorServidor


INDICE IIClienteHerramientas

PRUEBAS

Pruebas unitariasPruebas de integracionPruebas de rendimientoIntegracion Continua

CalidadCalidad

ConclusionesConclusionesLecciones aprendidasTrabajo futuro

BibliografıaBibliografıa


INTRODUCCION

I ¿Que es?I Un sistema para la gestion de vehıculos

I ¿Para que sirve?I Almacenar historicoI Centralizar datosI Controlar el mantenimiento

I Diferencias con otros productosI SensillezI Portabilidad


METODOLOGIA

I Ciclo de desarrollo en espiral

I Fase de analisis

I Creacion de la arquitectura

I Fase de usuarios

I Fase de vehıculos

I Fase de rutas

I Fase de piezas


ORGANIZACION

I Analista: analisis, decision de tecnologıas a implementar ycreacion de la arquitectura.

I Programador Java: desarrollo del Servidor

I Programador Android: desarrollo de la aplicacion Cliente.

I Tecnico de Sistemas: busqueda e implementancion de laarquitectura mas idonea.


ESTIMACION DE TIEMPOS


ESTIMACION DE COSTES

Tarea Analista P.J2EE P.Android Tec. Sistemas Total

S - Analisis 674,80e - - - 674,8e

S - Arquitectura base 1.383,34e - - - 1.383,34e

S - Usuarios - 354e - - 354e

S - Vehıculos - 330,4e - - 330,4e

S - Rutas - 495,60e - - 495,60e

S - Piezas - 590e - - 590e

S - Correccion bugs - 590e - - 590e

C - Arquitectura base 2.361,80e - - - 2.361,80e

C - Usuarios - - 873,20e - 873,20e

C - Vehıculos - - 967,60e - 967,60e

C - Rutas - - 1.014,80e - 1.014,80e

C - Piezas - - 1.864,40e - 1.864,40e

C - Correccion bugs - - 708e - 708e

Implantancion - - - 977,2e 977,2e

Total 4.419,94e 2.360e 5.428e 977.2e 13.185,14e


ANALISIS FUNCIONAL

I Diagramas de casos de uso

I Especificacion de los casos de uso

I Diagramas de interaccion

I Requisitos de informacion


REQUISITOS NO FUNCIONALES

I Alta disponibilidad: tolerancia a errores en una instanciaI Escalabilidad: facil escalado anadiendo instancias al

cluster.I Seguridad: seguridad ataques o perdida de informacion

(backup).I Facil comunicacion: acceso sencillo desde cualquier

plataforma.I Fiabilidad: Reducir al maximo la posibilidad de error.I Rendimiento: Bajo tiempo de respuestaI Coste ajustado: El coste lo mas ajustado posible.


DISENO FISICO


DISENO LOGICO


INFRAESTRUCTURA


SERVIDOR

I ¿Que lenguaje de programacion?I Java 1.7

I ¿Que base de datos?

I

I ¿Que sistema de comunicacion?I JSONI Servicios REST

I API y DTO


SERVIDOR - FRAMEWORKS

I Base de datosI

I JPA

I Logica de negocioI Core

I Comunicacion RESTI SecurityI MVCI Dozer MapperI Jackson


CLIENTE

I Cualquier cliente servicios REST

I

I SDK propio

I

I Frameworks y libreriasI GSONI MPAndroidChart


HERRAMIENTASI

I

I

I TexMaker - LATEX


PRUEBAS UNITARIAS

I

I Cobertura superior al 80 %.I Automatizacion de pruebas.I 100 % test correctos para paso a produccion.

I

I Mock a otras clases o servicios.I Prueba unicamente el servicio en cuestion.

I EclEmma


PRUEBAS DE INTEGRACION

I

I Grabacion de pruebas.I Automatizada la navegacion por pantallas con llamadas al

servidor.


PRUEBAS DE RENDIMIENTO

I


INTEGRACION CONTINUA

I

I CompilacionI Ejecucion de test automaticamenteI Integracion con SonarQubeI Pasos a produccion


CALIDAD -Servidor


OBJETIVOS

I CumplidosI Objetivos funcionales.I Estabilidad, seguridad, escalabilidad, etc.I Coste ajustado.I Aprendizaje.

I A mejorarI Plataformas disponibles.I Rendimiento de la plataforma.I Planificacion del tiempo.


LECCIONES APRENDIDAS

I Punto de encuentro de los conocimientos adquiridos.I Arquitectura propia.I Uso de API.I Uso de DTOI Evitar el acoplamiento.I Eleccion de tecnologıa adecuada.


TRABAJO FUTURO

I Implementacion de sistemas de cache.

I Liberacion del codigo.

I Publicacion de la aplicacion.


BIBLIOGRAFIAMockito, “Mocks para JUnit, Mockito.” http://mockito.org/, 2014.

Spring, “Spring documentation.” http://spring.io/guides, 2015.

Hibernate, “Hibernate documentation.”http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/, 2015.

Apache, “Tomcat 7.” http://tomcat.apache.org/tomcat-7.0-doc/, 2015.

Debian, “Raspbian, Debian + Raspberry Pi.” http://www.raspbian.org/RaspbianDocumentation,2015.

Jenkins, “Jenkins, CI.” https://wiki.jenkins-ci.org/display/JENKINS/Use+Jenkins, 2015.

SonarQube, “SonarQube.” http://docs.sonarqube.org/display/SONAR/Documentation, 2015.

Google, “Android SDK.” https://developer.android.com/guide/index.html, 2015.

JUnit, “Test Unitarios Java, JUnit.” http://junit.org/project-info.html, 2014.

Robotium, “Test para Android.” http://robotium.com/pages/user-guide, 2014.

D. Felker, Android Appplication Development for Dummies.WILEY, 2011.

E. Finegan and R. Liguori, OCA Java SE 7.Mc Graw Hill, 2012.

J. C. Deepak Alur and D. Malks, J2EE Patterns, Best Practices and Design Strategies.Prentice Hall, 2008.

B. Cascales and P. Lucas, LaTeX, una imprenta en sus manos.A. D. I., 2000.

http://mockito.org/

http://spring.io/guides

http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/

http://tomcat.apache.org/tomcat-7.0-doc/

http://www.raspbian.org/RaspbianDocumentation

https://wiki.jenkins-ci.org/display/JENKINS/Use+Jenkins

http://docs.sonarqube.org/display/SONAR/Documentation

https://developer.android.com/guide/index.html

http://junit.org/project-info.html

http://robotium.com/pages/user-guide


¿Preguntas?

Gracias por su atencion

sistema m´ovil para la gesti´on de vehıculos

Documents