Ingeniería del Software 2013/2014.  Integrantes del proyecto  Ámbito del proyecto  Arquitectura adoptada  Principal trabajo realizado en el proyecto.

Presentación del tema: "Ingeniería del Software 2013/2014.  Integrantes del proyecto  Ámbito del proyecto  Arquitectura adoptada  Principal trabajo realizado en el proyecto."— Transcripción de la presentación:

1 Ingeniería del Software 2013/2014

2  Integrantes del proyecto  Ámbito del proyecto  Arquitectura adoptada  Principal trabajo realizado en el proyecto  Planificación final del proyecto  Principales conocimientos adquiridos  Principales problemas encontrados

3  Andrés Manuel Gamboa Meléndez(Jefe de proyecto)  Alejandro Magdaleno(Profesional)  David Garcia(Profesional, Secretario)  Ignacio Sancho(Profesional, Diseño)  Lorena Costa López(Profesional, Revisor)  Javier Benavides Saavedra(Supervisor)  Patricia Motoso González(Supervisor)

4 ÁMBITO DEL PROYECTO

5 Nuestro proyecto es GIC Bank. Este software será el responsable de gestionar el sistema interno de un banco, así como los productos del banco como son las cuentas, los clientes y las tarjetas. La aplicación estará orientada principalmente diseñada para escritorio, con la idea de permitir una posible ampliación web. Las funciones básicas, que podrán ser ampliadas y modificadas a lo largo del proyecto, según las necesidades del cliente serán: Ámbito del proyecto (1/2)

6 Ámbito del proyecto (2/2) Clientes Cuentas Préstamos Creación de informes Informes Transacciones y transferencias Transacciones y reintegros Resúmenes de cuentas  El software fue diseñado en un principio para implementarlo en Java, IBM RSA se encarga de generar parte del código automáticamente, la base de datos se realizará en formato relacional y de la gestión de las bases de datos del sistema se llevará a cabo mediante MySQL.

7 ARQUITECTURA ADOPTADA

8  Arquitectura Multicapa ◦ Presentación Presenta la información y de interactuar directamente con los usuarios o empleados del banco ◦ Negocio Lógica de la aplicación del GIC Bank, es la encargada de implementar las operaciones solicitadas por los usuarios ◦ Integración Acceso a datos o recursos, es la responsable de gestionar todos los elementos de información del sistema de información distribuida

9  Diagrama de Secuencia a nivel multicapa ◦ Crear una cuenta

10  Modelo Vista Controlador ◦ Modelo Pasivo

11  Patrones Aplicados (1) ◦ Fachada, Factoría, Singleton, Servicio de aplicación

12  Patrones aplicados (2) ◦ Data Access Object

13 PRINCIPAL TRABAJO REALIZADO EN EL PROYECTO

14 En este proyecto comenzamos 8 miembros y antes de la primera entrega uno de ellos decidió dejarlo y tuvimos que reorganizarnos a pocos días de la entrega, de hacer todo su trabajo entre todos. Desde el primer momento decidimos que el trabajo íbamos a asignarlo en partes equitativas para ser justos, pero que se podría ayudar o reasignar roles según las necesidades de cada momento. Principal trabajo realizado en el proyecto (1/5)

15 Nuestro jefe de grupo, Andrés Gamboa nos ha ido gestionando los tickets tras las reuniones organizadas, donde hemos asignado los trabajos a realizar. También colaboro en el Diagrama de clases modificándolo hasta adaptarlo al final. Patricia Motoso ha sido gran participe en la adaptación al formato de la plantilla de todos y cada uno de los documentos que hemos ido subiendo a Assembla. También contribuyo a la gestión del proyecto. Principal trabajo realizado en el proyecto (2/5)

16 Ignacio Sancho se encargo de la codificación, las pruebas de nuestro proyecto y como todos de las tareas comunes del proyecto. Alex Magdaleno y Javier Benavides fueron los encargados principales del diseño y arquitectura del proyecto. También contribuyeron a todas las tareas comunes. David García y Lorena Costa han sido los encargados del análisis y diseño del proyecto, a parte de la colaboración común de todas las tareas asignadas. Principal trabajo realizado en el proyecto (3/5)

17 En, mayor o menor medida, todos hemos ido revisando los archivos, viendo los posibles errores y como poder solucionarlos. El trabajo con más volumen y más laborioso, como puede ser el de los casos de usos, se repartió por partes y a cada uno se le repartieron un numero de casos de usos a realizar. También, en el caso de los patrones de diseño, nos repartimos el trabajo, y cada uno fue el encargado de un patrón de diseño, de su desarrollo, de su explicación y como ha sido utilizado en nuestro proyecto. Principal trabajo realizado en el proyecto (4/5)

18 Queremos recalcar, que nos hemos ayudado unos a otros, porque ha sido difícil cuadrar horarios y mucho más en momentos claves del curso donde se nos acumulaban tareas. En definitiva todos hemos intentado hacer el trabajo lo mejor posible, proponiendo ideas, trabajando e implicándonos para poder llevar a cabo todo este proyecto del año. Principal trabajo realizado en el proyecto (5/5)

19 PLANIFICACIÓN FINAL DEL PROYECTO

20 Diagrama de Gantt Inicial

21 Diagrama de Gantt Real

22 - Desde el inicio vamos con retraso respecto a la planificación inicial, y los plazos se cumplen tarde. - Los retrasos, pese a la previsión y al margen con el que se cuenta desencadenan a su vez en nuevos retrasos, produciendo un efecto dominó. - Pese a dificultades para poder quedar todos conseguimos hacer una reunión antes de Semana Santa donde sacamos una primera iteración del Diagrama de Actividad - Semana Santa y el puente de Mayo muy desaprovechados, y a su fin contamos con un escaso mes y medio para acabar. - Faltan personas por hacer su iteración del Diagrama de Actividad seguimos con lo que ya está para no retrasarnos aún más. - Según se acerca el final del proyecto además coinciden en el tiempo entregas, practicas de laboratorio, y el final del cuatrimestre en general lo cual produce nuevos retrasos - El tiempo para desarrollar tareas queda muy comprimido, y se produce un sprint final para acabar antes del plazo de entrega. - Ser tantos, la dificultad para reunirnos, incumplimiento de plazos, y una mala previsión de cómo seria el final de curso, factores clave de no haber podido cumplir la planificación Real Inicial

23 PRINCIPALES CONOCIMIENTOS ADQUIRIDOS

24  A lo largo de todo el curso hemos realizado un proyecto a pequeña escala, partiendo desde cero y con conocimientos escasos sobre que es un proyecto.  Hemos adquirido diversos conocimientos desde:  QUE ES LA IS ◦ Es una disciplina de ingeniería. ◦ Aplicación de teorías métodos herramientas para realizar software que sea fiable y trabaje en maquinas reales. ◦ Teniendo en cuenta restricciones financieras, organizaciones y técnicas.  SENTIDO COMUN ◦ Planificar antes de desarrollar. ◦ Diseñar antes de programar. ◦ Reutilizar diseños que funcionan y son mantenibles.  DESARROLLO Y MANTENIMIENTO DE SOFTWARE ◦ Personas. ◦ Producto. ◦ Proceso.

25  PROCESO DE DESARROLLO ◦ Entender que es el proceso de desarrollo de software. ◦ Cuales son los componentes que debe considerar un proceso de desarrollo software. ◦ Calidad del proceso de desarrollo de software.  INGENIERIA DE REQUISITOS ◦ Entender las dificultades de capturar las necesidades del cliente. ◦ Determinar que aspectos clave debemos capturar en los requisitos. ◦ Pautas para el proceso de capturar.  GESTION DE EQUIPOS ◦ Una mala gestionarlo.  Proyectos mal organizados.  Fechas imposibles de cumplir.  Sistemas que no cumplen lo que el usuario quería.  Sistemas imposibles de mantener.

26  GESTION DEL PROYECTO ◦ Un proyecto se ejecutara con éxito cuando:  Se entrega un producto satisfactorio según las necesidades del cliente.  Se hace cumpliendo con las restricciones establecidas(coste plazos recursos).  RIESGOS ◦ Todo aquello que puede afectar negativamente al proyecto. ◦ Valorar el tipo de riesgo que se presenta y la mejor manera para mitigarlo.  PRUEBAS ◦ Código generado de manera manual o autogenerado que nos ayudara a comprobar que nuestro proyecto funcione a la perfección. ◦ Fiabilidad

27 PRINCIPALES PROBLEMAS ENCONTRADOS

28  PROBLEMAS EN EL PERSONAL ◦ Abandono definitivo de uno de los miembros del equipo a finales de Diciembre que supuso una nueva redistribución de las tareas entre el resto de integrantes y por lo tanto más trabajo para cada uno de ellos. Debido a esto se produjo un retraso en la fecha limite propuesta en la planificación inicial. ◦ Equipo con poca experiencia a la hora de trabajar en un proyecto con un elevado número de integrantes.

29 ◦ Escaso conocimiento del software y falta de experiencia programando en lenguajes con los que se desarrollará la aplicación. Para ello hicimos uso de tutoriales encontrados tanto en libros como en internet. ◦ Conflictos de horarios entre los miembros del proyecto, tanto por responsabilidades profesionales, ya que algunos integrantes tenían horario limitado al tener que trabajar fuera del proyecto, como por incompatibilidad en los horarios académicos.  Debido a esto se organizaban reuniones en los que participaran un mayor número de personas, y aquellas que no pudieran acudir eran informados del trabajo que tenían que realizar a través de la aplicación Assembla o por dispositivos móviles

30 ◦ Mala organización entre los miembros del equipo, teniendo que sacar la mayor parte del trabajo en las 3 últimas semanas antes de la fecha límite de entrega.  Se organizó en una reunión varias fechas para ir entregando, por cada miembro distintas partes del proyecto, repartido de forma equitativa.  Por motivos ajenos al proyecto, aparte de los problemas anteriormente descritos, se fueron produciendo retrasos en todas las entregas por algún integrante del equipo y esto generó nuevos retrasos en las sucesivas entregas propuestas en la planificación inicial.

31  PROBLEMAS EN GESTIÓN DEL PROYECTO ◦ Cambios en el proyecto con respecto a las ideas iniciales debido a la falta de tiempo (interfaz gráfica para validar el proyecto, otras opciones bancarias como hipotecas, etc… )  PROBLEMAS TÉCNICOS ◦ Dejar de funcionar temporalmente la página desde la cual se hacía uso de la documentación como ayuda para realizar el proyecto.

32