... | @@ -78,21 +78,43 @@ Baby Buddy es una solución de código abierto y no tiene costos de licencia aso |
... | @@ -78,21 +78,43 @@ Baby Buddy es una solución de código abierto y no tiene costos de licencia aso |
|
|
|
|
|
![Mapa de Riesgos](./uploads/Imagenes/mapa_de_riesgos_baby_buddy.png)
|
|
![Mapa de Riesgos](./uploads/Imagenes/mapa_de_riesgos_baby_buddy.png)
|
|
|
|
|
|
## Alternativa 3
|
|
## miPediatra (Desarrollo propio)
|
|
|
|
|
|
|
|
|
|
|
|
El desarrollo propio implica crear una aplicación desde cero, adaptada específicamente a las necesidades del proyecto. Esta alternativa ofrece un mayor control y personalización, pero también conlleva riesgos asociados con la dependencia del conocimiento y habilidades de los desarrolladores así como problemas de escalabilidad y soporte.
|
|
|
|
|
|
### Arquitectura
|
|
### Arquitectura
|
|
|
|
|
|
|
|
La arquitectura de la aplicación se basaría en Java como lenguaje de backend, utilizando el Springboot framework, y el framwork de Vue 3 + Vite para el frontend, utilizando HTML, CSS y JS. La arquitectura también podría incluir bases de datos u otras soluciones de almacenamiento.
|
|
|
|
|
|
### Estimación
|
|
### Estimación
|
|
|
|
|
|
|
|
La estimación del tiempo requerido para el desarrollo propio dependerá del alcance y las características del proyecto, así como de la experiencia y habilidades de los desarrolladores. Se estima que el tiempo necesario para este proyecto sería de aproximadamente 2 meses.
|
|
|
|
|
|
### Valoración económica
|
|
### Valoración económica
|
|
|
|
|
|
|
|
La valoración económica para el desarrollo propio consistiría en el salario del equipo de desarrolladores. 2200€ al mes, que estimando que el tiempo de desarrollo sean 2 meses, haría un total de 4400€ al contar con un único desarrollador.
|
|
|
|
|
|
|
|
Para este proyecto, se utilizará software gratuito por lo que no conllevaría costes adicionales.
|
|
|
|
|
|
|
|
Se estima que el mantenimiento del SI a desarrollar sería de 100€ al mes mientras se quiera renovar el contrato de mantenimiento.
|
|
|
|
|
|
### Riesgos
|
|
### Riesgos
|
|
|
|
|
|
|
|
- R1: Cambios en los requisitos del proyecto durante el proceso de desarrollo.
|
|
|
|
- Probabilidad: Posible.
|
|
|
|
- Impacto: Moderado.
|
|
|
|
- Mitigación: Seguir la metodología Combat Agile con Sprints de corta duración para mantener un feedback oportuno con los steakholders.
|
|
|
|
|
|
|
|
- R2: Dificultad en la escalabilidad y rendimiento de la aplicación.
|
|
|
|
- Probabilidad: Improbable
|
|
|
|
- Impacto: Mayor
|
|
|
|
- Mitigación: Diseñar la aplicación teniendo en cuenta la escalabilidad y el rendimiento desde el principio, para garantizar que pueda adaptarse a un mayor número de usuarios y a las necesidades cambiantes del proyecto.
|
|
|
|
|
|
|
|
- R3: Estimaciones inexactas de tiempo y recursos necesarios para el desarrollo.
|
|
|
|
- Probabilidad: Posible
|
|
|
|
- Impacto: Menor
|
|
|
|
- Mitigación: Realizar un análisis detallado de los requisitos y desarrollar estimaciones realistas. Revisar y actualizar regularmente las estimaciones a medida que avanza el proyecto.
|
|
|
|
|
|
|
|
![Mapa de Riesgos](./uploads/Imagenes/mapa_de_riesgos_miPediatra.png)
|
|
|
|
|
|
[Volver](Home) |
|
[Volver](Home) |
|
|
|
\ No newline at end of file |