Este documento describe una empresa de software llamada Embarcadero Technologies y propone un nuevo sistema de información para mejorar la coordinación entre sus departamentos. El sistema utilizará la metodología XP y tendrá requisitos funcionales como autenticación de usuarios, creación de proyectos y gestión de tareas, así como requisitos no funcionales de rendimiento, seguridad, fiabilidad y disponibilidad.

1. Embarcadero Technologies
Estudio de la empresa
Juan Fran Rubiales Victoria
Néstor Jódar Toledo
Fran Álvarez Álvarez
Néstor Rosario Escolano

2. Introducción
● Empresa de estudio “Embarcadero Technologies”.
● Empresa con diversos departamentos con bastante flujo de trabajo entre ellos.
● Necesidad de una buena coordinación.

3. 1. Descripción de la empresa
● Compañía de software norteamericana fundada en 1993.
● Empresa con alrededor de unos 500 empleados con presencia en 29 países.
● Ofrece servicio a más de tres millones de usuarios en miles de compañías y
organizaciones alrededor del mundo.

4. 1.1 ¿Qué hace?
● Embarcadero se ha dedicado desde que se fundó a la creación de herramientas de desarrollo,
IDE's y compiladores.
● Ofrece a sus clientes las herramientas necesarias para diseñar, desarrollar y utilizar sus base
de datos y aplicaciones en los sistemas operativos y plataforma que ellos elijan, reduciendo
costes y limitaciones.
● Embarcadero ofrece servicio a vendedores independientes de software, analistas de sistemas,
organizaciones gubernamentales, fabricantes de equipos, OEMs (Original Equipment
Manufacturer), empresas del sector de las tecnologías de la información y de I+D

5. 1.2 Estructura
● Embarcadero Technologies está formado por 6 departamentos:
o Secretaría: Atención al público, manejo general de documentos y gestión.
o Departamento de Recursos humanos: Planificación, formación y selección del personal.
o Departamento de Calidad: Departamento dedicado a la supervisión del desempeño del departamento de
desarrollo.
o Departamento Contable: Encargado de implementar las políticas, normas y los procedimientos necesarios para
garantizar una buena gestión de las operaciones financieras y presupuestales.
o Departamento Comercial: Encargado de las ventas, compras y marketing.
o Departamento de Desarrollo: Departamento dedicado al desarrollo de la solución

6. 1.2.1 Estructura - Organigrama

7. 1.3 Delimitación del proyecto
● Empresa un con un gran sistema de información, pero con inconvenientes:
○ Uso de múltiples aplicaciones.
○ Descoordinación entre los departamentos.
○ Menor productividad.
○ Menor respuesta en la demanda de trabajo.
● Propuesta de un nuevo sistema de información para la empresa.
● Nuestro sistema nace de la idea de mejorar la organización y coordinación actual entre los
departamentos de la empresa.

8. 1.3.1 Características principales
● Asistir a administradores de proyectos en el desarrollo de planes.
● Asignación de recursos a tareas.
● Seguimiento en el progreso.
● Administrar presupuestos.
● Analizar cargas de trabajo.

9. 1.3.2 Beneficios y metas
● Mejora en la coordinación entre departamentos.
● Aumentar la productividad.
● Empleados más operativos.
● Mayor respuesta a una demanda de los trabajadores.
● Incrementar la organización en los grupos de desarrollo de la empresa.

10. 2. Metodologías tradicionales
● Metodologías:
o ICONIX
 Descripción.
 Fases.
o MSF
 Descripción.
 Fases.
● Comparación.
● Elección.

11. 2.1 ICONIX
● Uso dinámico de UML.
● Se guía según los casos de uso.
● Iterativo e incremental.
● Requiere mayor documentación que XP: Requerimientos y diseño.
● Evita el sobre análisis.
● Reducción de los pasos entre análisis y diseño.

12. 2.1.1 Etapas
● Fase 1: Análisis de requisitos
o Modelo de dominio y casos de uso.
● Fase 2: Análisis y diseño preliminar
o Análisis de robustez (evitar errores en la desc. De los casos de uso). Actualizar modelo
de dominio. Detallar casos de uso.
● Fase 3: Diseño
o Usar los modelos de casos de uso y de dominio para diseñar diagramas de secuencia y de
clase, respectivamente.
● Fase 4: Implementación
o Utilizando los diagramas empezará a crearse el código.

13. 2.2 MSF (Microsoft Solutions Framework)
● Conjunto de procesos, principios y prácticas comunes en la ingeniería software.
● MSF4ASD se focaliza en los roles y cargos del equipo de desarrollo.
o Promover la comunicación.
o Trabajar a un objetivo común.
o Fortalecer a los miembros del equipo.
o Aumentar el valor del negocio.
o Invertir en calidad.
o Aprender de experiencias previas.

14. 2.2.1 Etapas
● Fase 1: Análisis
o Requisitos del negocio y metas del proyecto.
● Fase 2: Planificación
o Especificación de recursos necesarios y borrador general.
● Fase 3: Desarrollo
o Creación de las primeras versiones del producto, sin llegar al producto final.
● Fase 4: Estabilización
o Realización de pruebas.
● Fase 5: Implementación
o Trabajo listo para ser entregado, e incluye el proceso de mantención.

15. 2.3 Comparación
ICONIX:
● Ventajas:
o Énfasis en la documentación (simplificada).
o Evita la paralización.
o Análisis de robustez.
● Desventajas:
o No útil para proyectos grandes.
o Depende de la correcta captura de los requisitos y las estimaciones.

16. 2.3 Comparación
MSF:
● Ventajas:
o Vinculación con cliente y orientado al equipo de trabajo.
o Disciplina de análisis de riesgos.
● Desventajas:
o Excesiva documentación en cada fase.
o Dependencia de herramientas.

17. 2.4 Elección
● Elección de la metodología ICONIX
o Fácil uso
o Uso adecuado de la documentación
o Basado en requerimientos

18. 3. Metodologías ágiles
● Metodología SCRUM
o Descripción
o Aplicación
● Metodología XP
o Descripción
o Aplicación
● Elección

19. 3.1.1 Scrum: descripción
● Conjunto de tareas para trabajar colaborativamente y obtener el mejor resultado posible
o Utilización de iteraciones.
o Priorización según coste y valor.
o Trabajo en equipo.
o Comunicación.
● Fases:
o Preparación del proyecto o Sprint 0.
o Planificación del Sprint.
o Desarrollo del Sprint (Sprints).
o Cierre.

20. 3.1.2 Scrum: Aplicación
● Pila de producto:
o Grooming (Preparación): lista de priorización, detalle y estimación de las actividades.
● Planificación del sprint:
o Primera reunión: Metas y requisitos.
o Segunda reunión: Planificación de iteraciones.

21. 3.1.2 Scrum: Aplicación
● Roles necesarios para la aplicación de SCRUM:
o Product Owner: Toma de decisiones.
o Scrum Master: Modelo y metodología SCRUM.
o Equipo de desarrollo: no más de 5 a 8 personas.
o Usuarios
o Stakeholders
o Managers

22. 3.1.2 Scrum: Aplicación
● Beneficios:
o Productividad mediante comunicación y creación de sinergias.
o Potenciación del compromiso del equipo sobre el objetivo común de la iteración.
o Estimación conjunta en base a la experiencia.

23. 3.2.1 XP: Descripción
● Orientada fuertemente a la codificación, está pensada para equipos pequeños y entornos
dinámicos:
o Mayor coste. Mayor tiempo. Menor ámbito. Mayor calidad.
● Fases:
o Exploración.
o Planificación.
o Diseño.
o Producción.
o Pruebas.
o Mantenimiento.
o Muerte del proyecto.

24. 3.2.2 XP: Aplicacion
● Roles necesarios para la aplicación de XP:
o Programadores
o Jefe del proyecto
o Cliente
o Tester
o Rastreador
o Entrenador

25. 3.2.2 XP: Aplicacion
● Historias de usuario:
o Requisitos otorgados por el cliente que serán analizados en reuniones realizadas antes
de cada iteración.
● Historias por iteración:
o Debido a la complejidad del proyecto consideramos que se deberían realizar 2 historias
por iteración y que cada iteración no dure más de dos semanas.

26. 3.3 Elección
● Considerando que el proyecto que se realizará requiere un nivel de calidad alto y un manual
de usuario detallado, es preferible utilizar la metodología XP para tener la mayor cantidad
posible de documentación y pruebas.

27. 4. Requisitos
● Requisitos Software
1. Servicio de autentificación del cliente.
2. Implementación de la interfaz de usuario.
3. Creador y visor de proyectos.
4. Información de usuarios.
5. Gestor de tareas.
6. Gestor de Presupuestos.
7. Seguimiento de progreso
8. Diagrama de Gantt
9. Integración de MySql

28. 4. Requisitos
● Requisitos Hardware
1. Creación de servidores.
1. Creación del sistema de copias de seguridad.

29. 4.1 Requisitos de las interfaces
● Interfaces de usuario
Autentificación del usuario
LOGIN

30. 4.1 Requisitos de las interfaces
● Interfaces de usuario
LOGIN
Administrador
No Administrador

31. 4.1 Requisitos de las interfaces
● Interfaces de usuario
LOGIN
ADMINISTRADOR
NO
ADMINISTRADOR
PROYECTO

32. 4.1 Requisitos de las interfaces
● Interfaces Hardware
En 2 servidores se almacenará los
proyectos y usuarios
RED

33. 4.1 Requisitos de las interfaces
● Interfaces Hardware
Un servidor adicional para guardar
copias de seguridad
RED

34. 4.1 Requisitos de las interfaces
● Interfaces Hardware
RED

35. 4.1 Requisitos de las interfaces
● Interfaces Software
Base de datos MySQL que
almacenará los usuarios
y los proyectos a los que
pertenecen cada
usuario.
Proyecto 1
Usuario 1
Proyecto 2
Usuario 2
Proyecto 3
Usuario 3
….
….

36. 4.1 Requisitos de las interfaces
● Interfaces de comunicación
LOGIN BBDD
BBDD
BACKUP
BBDD
BACKUP

37. 4.2 Requisitos funcionales
● Acceso al sistema:
1. Entrada: Nombre y contraseña de usuario al iniciar la aplicación
➔ Necesita estar registrado en la base de datos del servidor
2. Se procesan los datos introducidos, verificando que se tiene permiso
para acceder
3. Salida: Una vez comprobado, se muestra por pantalla la interfaz y el
usuario puede empezar a trabajar

38. 4.2 Requisitos funcionales
● Creación de copias de seguridad:
1. Entrada: el administrador deberá programar el período con el que el
sistema ejecutará la operación
2. Salida: se creará una copia de seguridad de todos los datos
almacenados en el plazo fijado automáticamente
➔ Máximo 3, se borrará la más antigua antes de añadir nuevas

39. 4.3 Requisitos no funcionales
● Rendimiento:
- Conexión constante -> Tiempos de respuesta rápidos y seguros
- Objetivo: acceso del usuario al sistema < 5 segundos
- En caso de caída de la red u otros motivos, se podrá seguir
trabajando y guardar el progreso para la próxima vez que se conecte
a los servidores

40. 4.3 Requisitos no funcionales
● Seguridad:
- Acceso exclusivo a usuarios autorizados por el administrador
- Registros de ingreso y salida de cada usuario
- La empresa será la encargada de evitar las intrusiones externas

41. 4.3 Requisitos no funcionales
● Fiabilidad:
- Sólo los administradores podrán acceder a las secciones críticas
- En caso de error, se creará un ‘log’ indicando las últimas acciones
realizadas por el usuario

42. 4.3 Requisitos no funcionales
● Disponibilidad:
- La empresa cuenta con sedes en diferentes países, por lo que los
servidores deben funcionar el 100% del tiempo
- La aplicación necesita estar conectada a los servidores para
ejecutarse al inicio

43. 4.3 Requisitos no funcionales
● Mantenibilidad:
- Período de mantenimiento: 1 por semana
- Será el administrador el encargado de la tarea
- Se cerrarán los servidores temporalmente

44. 4.3 Requisitos no funcionales
● Portabilidad:
- Uso en sistemas Windows, abierto para otras plataformas en el
futuro
- Los servidores únicamente responden a la aplicación

45. 4.4 Otros requisitos
● Propiedad Intelectual
- La licencia tendrá un coste fijo anual, asignado a partir de las
características solicitadas por el cliente. Incluirá un mantenimiento
anual, con opción a semanal mediante otra licencia
● Impacto medioambiental
- La empresa puede usar nuestra herramienta para toda la gestión de
proyectos, por lo que no será necesario el gasto adicional que
supone imprimir la documentación en papel