Fase 4 Planificación proyecto de software

Presentado por:

Jesus Eduardo Muñoz Orozco

1061722625

Uriel David González Ramírez

1077969800

Carlos Eliecer Fajardo

1023921809

Kelly Johana Castro Torres

52982483

Tutora:

MARTHA YOLANDA DIAZ

Grupo: 301404_3

Universidad Nacional Abierta y a Distancia - UNAD

Escuela de Ciencias básicas, Tecnología e Ingeniería

Julio de 2021
 Introducción

El presente documento contiene el desarrollo de la fase 4 para el curso Ingeniería de Software

el cual busca planificar proyectos de desarrollo de software a través de referentes oficiales

internacionales en el marco de la fundamentación para la gestión de proyectos. El grupo de

trabajo colaborativo selecciono el estándar PMI para abordar 4 gestiones basicas para estimar

todo el proyecto:

1. Gestión del alcance.

2. Gestión del tiempo.

3. Gestión del costos.

4. Gestión de riesgos.
1. Gestión del alcance: objetivos del software, entregables, EDT y especificación de
requerimientos.

Objeto del proyecto: Desarrollar un software que permita a los usuarios consultar servicios

de medicina especializada de manera anónima y gratuita para recibir respuesta por personal

profesional en las diferentes áreas de salud, dependiendo el interés.

Objetivos del software:

- Consultar servicios de medicina especializada de manera anónima y gratuita.

- Brindar información de medicamentos, enfermedades, síntomas, y procedimientos que

pueden ser consultados en la base de conocimiento certificada.

- Brindar la posibilidad de obtener perfil digital para especialistas y servir de puente para

tener acceso a clientes potenciales.

Alcance:

- El software será web.

- El software únicamente será para la comunidad hispano hablante.

- Las áreas especializadas con las que se trabajara son: medicina general, dermatología,

pediatría, medicina interna, ginecología y obstetricia, urología, infectología,

planificación, sexología, farmacología y ortopedia.

 EDT

Proyecto de software
Medical Software
S.A.S

Contextualización Planificación Desarrollo Evaluación

Revisar la ejecución
Estudiar y socializar la
Identificar Ejecución de las fases del sfotware de
propuesta con el
requerimientos. del cronograma acuerdo al plan de
equipo de trabajo
trabajo

Desarrollar el acta de
Crear el plan de Monitorear los
constitución del Programación
dirección de proyecto procesos
proyecto.

Definir actividades a Documentar el

Documentar los
desarrollar y uso de desarrollo en cada
resultados
recursos versión

Definir un
Adquisición de
cronograma de
recursos
trabajo

Especificación de requerimientos:

A continuación, el detalle de los requerimientos funcionales y no funcionales:

Numero Requerimiento
01 El sistema permitirá hacer consultas médicas en habla hispana en
cualquier momento de manera gratuita y anónima para los usuarios.
02 El sistema permitirá el registro de médicos generales y especialistas.
03 El sistema deberá guardar todas las consultas que se realicen por los
usuarios para tener un repositorio de temas relacionados con salud.
El sistema deberá guardar el registro de médicos generales y especialistas.
04
El sistema permitirá a los usuarios consultar el repositorio de temas
05 preguntados con anterioridad.
06 El sistema deberá evaluar los registros de los médicos y especialistas.
07 El sistema deberá aceptar los registros de los médicos y especialistas de
habla hispana una vez hayan sido evaluados.
08 El sistema permitirá a los médicos y especialistas aceptados iniciar sesión.
09 El sistema permitirá a los médicos y especialistas responder a las
solicitudes recibidas de quienes hagan uso del sistema.
10 El sistema deberá dirigir las solicitudes al médico especialista de acuerdo
con su especialidad de formación.
11 El sistema deberá permitir que los usuarios califiquen con ítem de una a
cinco estrellas las repuestas brindadas por los médicos.
12 El sistema deberá permitir a los médicos y especialistas un perfil digital.
13 El sistema deberá contar con información y asesoría relacionada con
medicamentos, enfermedades, síntomas y procedimientos.
14 El sistema no deberá tener pautas publicitarias.
15 El sistema deberá funcionar para cualquier usuario (persona, empresa,
aseguradora).
16 El sistema deberá contar el número de respuestas brindadas por cada
médico o especialista y mejorar su perfil digital.
17 El sistema debe redirigir las consultas de manera balanceada cuando
hayan más de un mismo especialista de la misma rama conectado
respondiendo consultas.
18 El sistema debe tener estadísticas de los médicos y especialistas que
permitan medir su reputación para proporcionarles clientes potenciales.
19 El sistema deberá denegar el registro cuando un médico o especialista no
adjunte los documentos correspondientes o la información adjuntada no
sea verídica.
20 El sistema deberá tener auditoría de las acciones realizadas por los
usuarios en un log que almacene la acción, el usuario y las horas de cada
una de ellas.
21 El sistema deberá tener copias de seguridad periódicas que permitan hacer
restauraciones completas en caso de fallas críticas.
22 El sistema deberá permitir la visualización y navegación web sobre las
diferentes opciones, así como la visualización de documentos a través de
un navegador de internet.
23 El sistema deberá proporcionar una interfaz web sencilla de usar.
24 El sistema deberá notificar por correo electrónico a los médicos o
especialistas cuando cumplan más de una semana sin conectarse.
25 El sistema deberá contar con un mecanismo de recuperación de
contraseña mediante código al celular o correo electrónico para los
médicos o especialistas que se encuentren registrados.
26 El sistema deberá realizar búsquedas en 3 segundos.
27 El sistema deberá estar disponible 24 horas al día, 7 días de la semana y
364 días al año.
28 El sistema deberá tener contingencia.
29 El Periodo de inactividad no prevista del sistema no debe superar las 24
horas al año.
30 El sistema deberá cerrar la sesión por inactividad después de 10 minutos
para los doctores o especialistas.
31 El sistema deberá ser funcional en internet explorer, mozilla, Firefox.
32 El sistema deberá tener aceptación de términos y condiciones.
33 El sistema deberá permitir la actualización y/o modificación de datos de
los médicos o especialistas.
Sprint 1: levantamiento de información

En esta fase de se reúnen los involucrados del proyecto para hacer el plan de trabajo, discutir

los requerimientos dados por los dueños del proyecto en la fase inicial, objetivos,

funcionalidades, riesgos del sprint, plazos de entrega y características. Se asignan los roles de

cada integrante del equipo trabajo respecto al proyecto.

Se hará también la recolección de información durante una semana por parte del equipo de

desarrollo, esta se hará con encuestas cuantitativas mixtas para obtener información de personas

del público objetivo como lo son: personas del común, farmaceutas, doctores, especialistas,

estudiantes de medicina, acerca de su opinión o aceptación del proyecto, tipos de interfaz de

chat, enfermedades más usuales, especialistas a que más recurren, medicamentos más usados,

información útil que pueda llevar a generar mejoras.

También una encuesta abierta de carácter cualitativo de parte del scrum master y el product

owner a los clientes dueños del proyecto para obtener ideas, un acercamiento y visión sobre el

proyecto. Las siguientes dos semanas del sprint se organiza la información en limpio.

Posteriormente se realiza una reunión entre los clientes dueños de la aplicación, los sponsors

y el equipo de trabajo para exponer cómo se desarrollará cada punto del intervalo. Se tomarán

decisiones, evaluarán cambios, se harán mejoras y demás valores para elaborar un buen producto

final.

Entregables: Actas de reuniones con los involucrados del proyecto, información organizada de

los datos obtenidos en las encuestas.

Sprint 2: Cotejo de información

En esta fase el product owner analiza los datos de los entregables que se diligenciaron en la

fase anterior y se relacionan con los objetivos y requerimientos para direccionar el proyecto.

Se definen que especialidades de medicina estarán disponibles en la aplicación, en una

versión 1.0 estarán las siguientes especialidades: medicina general, hasta especialidades como

dermatología, pediatría, medicina interna, ginecología y obstetricia, urología, infecto logia,

planificación, sexología, farmacología y ortopedia.

El scrum master supervisa al product owner y definen las historias de usuario para empezar a

desarrollar el producto.

Entregables: Especialidades de la medicina que estarán disponibles en la aplicación, historias

de usuario, requerimientos actualizados.

Sprint 3: Modelado de mockups

Con los entregables de la fase anterior el equipo de desarrollo procede a hacer los mockups de

una primera impresión de la aplicación.

Habiendo dejado en claro los objetivos y las características de nuestro proyecto se hará un

modelado de los siguientes módulos:

- Pantalla bienvenida de la aplicación.

- Pantalla de registro de la aplicación.
- Módulo de preguntas a interrogantes acerca de salud, selección de profesionales.
- Módulo de historial de preguntas.
- Módulo de perfil del profesional en salud.
- Modulo del historial de preguntas
 Con la ayuda de los mockups se pueden ajustar o mejorar las historias de usuario.
Entregables: Mockups de las pantallas mencionadas, historias de usuario definitivas del

proyecto.

Sprint 4: Informe general de avance del proyecto y elección de base datos

Se hace una reunión con todos los involucrados en el proyecto para presentar avances al

cliente y demás stakeholders y en conjunto con este hacer los cambios pertinentes o las mejoras

necesarias.

Los mockups y las historias de usuario se evalúan y se ajustan dependiendo a las decisiones

del equipo y stakeholders.

Se procede a seleccionar las herramientas de base de datos las cuales van a soportar el

proyecto y que se ajustan más a las necesidades y tamaño de este. El scrum master hace una lista

tentativa de tres opciones se exponen a los stakeholders y junto con el equipo de trabajo eligen la

mejor opción.

El equipo de desarrollo hace el modelado de las bases de datos relacionales con sus

respectivas tablas de doctores, usuarios, preguntas e historial.

- Reunión de 5 horas con stakeholders.

- El resto del sprint elaboración de base de datos

Entregables: Actas de reunión con los involucrados del proyecto con conclusiones y mejoras

a realizar al proyecto, modelado de base de datos con sus respectivas tablas y relaciones, product

backlog actualizado.
Sprint 5: Desarrollo de pantallas de aplicación

Para esta fase ya el proyecto está listo para ser desarrollado.

Los 3 ingenieros desarrolladores reciben mockups presentados en el sprint 3 y diseño de bases

de datos, estos inician con las pantallas de la aplicación y luego su conexión a la base datos.

El trabajo se reparte de la siguiente manera.

- Ingeniero 1 y 2: pantallas de la aplicación. (sprint 3)

- Ingeniero 3: construcción de base de datos

Por otra parte, el equipo completo realiza 5 opciones de logos para la aplicación, 5 slogans y 5

opciones de paletas de colores explicando el porqué de su elección. (1 ítem por miembro)

Entregables: Pantallas desarrolladas, base de datos construida y lista para hacer conexión,

cada integrante del equipo incluyendo product owner y scrum master deben realizar un informe

sobre esta fase y tenerlo listo para la siguiente, este debe indicar todos los inconvenientes y

mejoras por realizar (si las hay).

Sprint 6: Implementación de mejoras

El scrum master convoca una reunión con todos los involucrados en el proyecto para

presentar avances y documentación en especial al cliente y en conjunto con este y demás

stakeholders hacer los cambios pertinentes o las mejoras necesarias antes de hacer conexión con

base datos.
 Se evalúan todos los productos de entregas anteriores sobre todo del sprint número 6, se

presentan los logos, slogans y paletas de colores y se eligen los adecuados para el proyecto de

forma consensuada por todos los involucrados del proyecto.

Con las decisiones tomadas el equipo de desarrollo procede a aplicar las mejoras al diseño y

se hace la conexión con la base de datos con la aplicación.

- Reunión de 5 horas con stakeholders.

- El resto del sprint implementación de mejoras y base de datos.

Entregables: Elección de logo, Slogan y paleta de colores, conexión exitosa a base de datos y

sin errores al ingresar registros, acta de reunión.

Sprint 7: Reunión de ensamblado

El equipo y todos los involucrados se reúnen para ver el ensamblado de la versión 1.0 del

producto para las respectivas pruebas, correcciones y cambios no mayores que se consideren

necesarios.

Se analiza el rendimiento de la aplicación y se toman decisiones respecto al diseño, velocidad

de instalación y entorno.

- Reunión de 4 horas con stakeholders.

- El resto del sprint implementación de mejoras al diseño velocidad de instalación y

entorno.
 Entregables: Informe general sobre el desempeño de la versión 1.0 de la aplicación

ensamblada incluyendo logo, slogan y paleta de colores.

Sprint 8: Reunión de presentación

El equipo de desarrollo hace las correcciones aportadas en el sprint anterior y se inician las

últimas pruebas piloto antes de ser comercializado el producto final.

El equipo con la aprobación del cliente y de todos los miembros del equipo presenta el

producto terminado para ser comercializado al público y se entrega toda la documentación del

proyecto.

Se programan las fechas de mantenimiento del producto durante los próximos 15 días

calendario en cualquier momento en caso de falla.

Entregables: Acta de entrega de documentación, código fuente y demás archivos.

2. Gestión del tiempo: con listado de actividades, secuencia de actividades, cronograma

(diagrama Gantt), etc.

PENDIENTE
3. Gestión de costos: listado de rubros, estimación de costos, presupuesto del proyecto

PENDIENTE

4. Gestión de riesgos: lista de riesgos, análisis de cada riesgo (prioridad, probabilidad,

impacto, tratamiento).

PENDIENTE
 CONCLUSION

- El ejercicio desarrollado permite una comprensión correcta de los principales elementos y

características en la ingeniería de software.

- La ejecución de esta actividad nos permite encontrar la aplicación en la vida real para la

solución de problemas usando el conocimiento en ingeniería de software.

- El desarrollo del ejercicio identificando los fundamentos básicos en ingeniería de

software nos permite adquirir competencias indispensables que se aplicaran en nuestro

entorno profesional.
 REFERENCIAS BIBLIOGRÁFICAS

Weitzenfeld, A. (2013). Modelo de Proceso. En Ingeniería de Software Orientada a Objetos con

UML, Java e Internet (pp. [35]-50). Mexico City, Mexico: Cengage Learning. Recuperado de

http://bibliotecavirtual.unad.edu.co:2619/apps/doc/CX3004300023/GVRL?

u=unad&sid=GVRL&xid=23dc4521

Weitzenfeld, A. (2013). Modelos Clásicos. En Ingeniería de Software Orientada a Objetos con

UML, Java e Internet (pp. 50-54). Mexico City, Mexico: Cengage Learning. Recuperado de

http://bibliotecavirtual.unad.edu.co:2619/apps/doc/CX3004300024/GVRL?

u=unad&sid=GVRL&xid=69d44b62

Weitzenfeld, A. (2007). Modelos Recientes. En Ingeniería de Software Orientada a Objetos con

UML, Java e Internet (pp. 54-56). Mexico City, Mexico: Cengage Learning. Recuperado de

http://bibliotecavirtual.unad.edu.co:2619/apps/doc/CX3004300025/GVRL?

u=unad&sid=GVRL&xid=8d8a7106

Puchades Rodríguez, M. (2020). Estado del arte de las metodologías de desarrollo ágil. Editor:

E.T.S.I de Sistemas Informáticos (UPM). Disponible en: http://oa.upm.es/62684/ Recuperado de

https://bibliotecavirtual.unad.edu.co/login?url=http://search.ebscohost.com/login.aspx?

direct=true&db=edsbas&AN=edsbas.6578DC21&lang=es&site=eds-live&scope=site
Schwaber, K. & Sutherland, J. (2013). La Guía definitiva de Scrum: Las reglas del juego.

Recuperado de http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf

Instituto Nacional de Tecnologías de la Comunicación. (2011). Software e Ingeniería de

Software. Curso de introducción a la ingeniería del software. (pp. [10]-21). Recuperado de

http://jmpovedar.files.wordpress.com/2011/08/curso-de-introduccic3b3n-a-la-ingenieria-del-

software.pdf

Ebert, C., Kuhrmann, M. & Prikladnicki, R. (2016). Global Software Engineering: Evolution and

Trends. 2016 IEEE 11th International Conference on Global Software Engineering (ICGSE),

9(1), 112-115. Recuperado de http://bibliotecavirtual.unad.edu.co:2052/stamp/stamp.jsp?

tp=&arnumber=7577432

Weitzenfeld, A. (2013). Proceso de Software. En Ingeniería de Software Orientada a Objetos con

UML, Java e Internet (pp. [35]-50). Mexico City, Mexico: Cengage Learning. Recuperado de

http://bibliotecavirtual.unad.edu.co:2619/apps/doc/CX3004300022/GVRL?

u=unad&sid=GVRL&xid=05ae9517

Rob, P., & Coronel, C. (2014). Ciclo de Vida de Desarrollo de Sistemas (SDLC, por sus Siglas

en Inglés). En Sistemas de bases de datos: Diseño, implementación y administración (5th ed., pp.

322-325). Mexico City, Mexico: Cengage Learning. Recuperado de

http://bibliotecavirtual.unad.edu.co:2619/apps/doc/CX4059200079/GVRL?

u=unad&sid=GVRL&xid=0d15e618