Entrega Final Semana 7

lOMoARcPSD|15259203
Entrega Final semana 7
Ingeniería de Software I (Politécnico Grancolombiano)
Studocu no está patrocinado ni avalado por ningún colegio o universidad.

Descargado por Edison Andres Rojas Angarita (edison011991@gmail.com)
lOMoA
Entrega Final Ingeniería de Software 1
María Fernanda Barrero Rincón
Yesid Fernando Amaya Porras
Jhonathan Artunduaga Almario
Edinson Balaguera Rodríguez
Facultad de Ingeniería, Diseño e Innovación, Institución Universitaria Politécnico
Grancolombiano
Grupo 3 - Ingeniería de Software 1
Wilson Manuel Mantilla Velasco
2021
Descargado por Edison Andres Rojas Angarita

lOMoA
Resumen
En el presente documento se pretende exponer las características, ventajas y
desventajas de cada tipo de metodología de desarrollo de software e identificar la que mejor
se adapte a un sistema de agendamiento de citas médicas e implementarla según las
necesidades del cliente.
Introducción
El éxito de un proyecto de software se define gracias a una gestión correcta de
requisitos, buena comunicación con el cliente, entregas a tiempo y una correcta elección de un
modelo de procesos.
Las metodologías tradicionales y ágiles ofrecen diversos modelos de procesos,
diferenciar cada uno de ellos y conocer cómo aplicarlos al desarrollo de un proyecto de
software marcará una diferencia entre el éxito y el fracaso de dicho proyecto.
Para lograr discrepar cada uno de ellos, es necesaria la investigación teniendo
en cuenta su definición, ventajas, desventajas y finalmente, una comparación de estos
para asegurar una correcta elección de acuerdo con el proyecto planteado por el cliente.

lOMoA
Objetivos
Objetivo general
Generar la documentación para desarrollar un software que permita el registro
de profesionales de la salud para ofrecer agenda de sus servicios.
Objetivos específicos
1. Consultar y escoger la metodología que más se adapte al desarrollo del software.
2. Definir las actividades y roles de los miembros del equipo dentro del desarrollo de
software.
3. Diseñar los diagramas de actividades, diagramas de estado y el diagrama de clases.

lOMoA
Metodologías Tradicionales
El desarrollo del trabajo enfatiza en la planificación total del trabajo y una vez está
determinado, se inicia con el ciclo del desarrollo de un producto de software, además, se
centra en llevar una documentación de todo el proyecto y cumplir a detalle el plan de proyecto.
Otra característica fundamental es el alto costo que tiene el implementar cambios, no
ofrece una buena solución a proyectos que son inestables, es decir, que cuentan con una
gran probabilidad de sufrir cambios de requerimientos durante el desarrollo.
Dentro de las metodologías tradicionales se encuentran los siguientes modelos
de procesos:
• Modelo En Cascada.
• Modelo De Procesos Incremental.
• Modelo De Procesos Espiral.
Metodologías ágiles
Mientras que, las metodologías tradicionales enfatizan en la especificación de todo
antes de comenzar el desarrollo, las metodologías ágiles hacen énfasis en obtener
resultados satisfactorios para el cliente y la capacidad de respuesta a un cambio dentro del
proyecto.
Las metodologías ágiles nacen gracias al manifiesto ágil.
Dentro de las metodologías ágiles se encuentran los siguientes modelos de procesos:
• Extreme Programming.
• Crystal Methodologies.
• Desarrollo adaptativo de software.

lOMoA
• Team Software Process.
• SCRUM.
• Método De Desarrollo De Sistemas Dinámicos (DSDM).

lOMoA
Diferencias entre metodologías
Canós, J. (2005) resume las características de ambas metodologías, en la siguiente
tabla:
Metodologías ágiles Metodologías tradicionales
Se basan en heurísticas provenientes de prácticas de Se basan en normas provenientes de estándares

producción de códigos. seguidos por el entorno de desarrollo.
Preparados para cambios durante el proyecto. Cierta resistencia a los cambios.
Impuestas internamente por el equipo. Impuestas externamente.
Proceso menos controlado, con pocos principios. Proceso muy controlado, numerosas normas.
Contrato flexible e incluso inexistente. Contrato prefijado.
Cliente interactúa con el equipo de desarrollo mediante
El cliente es parte del desarrollo. reuniones.
Grupos pequeños (<10). Grupos grandes.
Pocos artefactos. Más artefactos.
Menor énfasis en la arquitectura del software La arquitectura del software es esencial.
Fuente: Canós, J et al, 2005. Metodologías Ágiles.
A parte de las características de cada metodología con respecto a la otra, en
la siguiente tabla se muestra cómo se comporta cada una según la etapa del
proyecto:
Metodología tradicional Etapa Metodología ágil
Análisis de requisitos Planificación adaptativa: Entregas

Planificación predictiva y “aislada”. frecuentes + colaboración del
Planificación cliente.
Diseño flexible y extensible + Diseño Simple: Documentación
modelos + documentación Diseño mínima + Focalizado en la
exhaustiva. comunicación.
Transferencia de conocimiento:
Desarrollo individual con roles y
Codificación Programación en pares +
responsabilidades estrictas.
conocimiento colectivo.
Pruebas Liderazgo-Colaboración:
Actividades de control: Orientado a
empoderamiento +
los hitos + gestión mini proyectos. Puesta en producción autoorganización.
Fuente: Figueroa, R et al., s.f. Metodologías tradicionales vs. metodologías ágiles.

lOMoA
Modelo de procesos para abordar el proyecto: DSDM
El modelo de procesos elegido para abordar el proyecto es DSDM, perteneciente a
la metodología ágil.
Su elección se basa debido a que provee un entorno de trabajo para el desarrollo ágil
de software, emplea un ciclo de vida iterativo cuyo objetivo es detallar el plan conforme
avanza el proyecto.
El DSDM cuenta con las siguientes características:
1. Participación del usuario para ser más eficaces y precisos en el desarrollo
del proyecto.
2. El desarrollo es iterativo e incremental permitiendo la realización de cambios
no previstos durante el desarrollo del proyecto.
3. Las entregas son cortas pero funcionales ya que abordan las funcionalida
des críticas del proyecto y se presenta una mejora en cada una de ellas.
4. Todos los cambios son reversibles ya que se cuenta con una línea base la cual
sirve para cuando un cambio no cumple con lo requerido, se puede volver a ella.
5. Se integran pruebas en cada fase para evitar costes a futuro.
6. El equipo puede realizar cambios importantes sin esperar la autorización de
un superior.
Resaltando las características 1, 4 y 6 para tomar la elección de esta metodología,
debido a que:
• Se considera fundamental la participación y comunicación del usuario para el éxito
del proyecto.
• Puede suceder la implementación de cambios por sugerencia del usuario y una
vez mostrado al mismo quiere realizar un retroceso de este, DSDM permite revertir
los

lOMoA
cambios ya realizados a una línea estable del proyecto, esto se puede comparar
con un control de versiones de código.
• Debido a que el equipo de trabajo es pequeño (4 integrantes) las decisiones
tomadas para realizar los cambios sugeridos por el usuario se pueden realizar sin
la necesidad de contar con una autorización por la cabeza del equipo, es decir,
todos tienen el mismo acceso y permiso para la realización de cambios.

lOMoA
Principales riesgos del DSDM
Los principales riesgos asociados al uso de esta metodología son los siguientes:
• La comunicación con el usuario no se realiza adecuadamente o incluso es
inexistente.
• El equipo al tener el poder de decidir sobre cambios importantes puede que tenga
un enfoque erróneo de los mismos, generando retrasos en las entregas.
• Se complica el entender su proceso, aplicación e implementación.
¿Cómo mitigar dichos riesgos?
• Comunicación constante entre los miembros del equipo para tener claros los
requerimientos y actividades a realizar, evitando así cambios constantes e
innecesarios que retrase las entregas.
• Constante aprendizaje e indagación sobre el proceso y fases acerca del DSDM
para poder aplicar e implementar las ideas y soluciones precisas en el desarrollo del
proyecto de software.
• A pesar de ser una metodología de libre elección de cada integrante al momento de
realizar cambios se podría implementar la opción de debatir los cambios a realizar
con el equipo completo, para así no correr el riesgo de retrasar el proyecto ni tener
complicaciones a futuro.

lOMoA
¿Por qué no usar los otros modelos de procesos?
En la siguiente tabla se explica los modelos de procesos mencionados previamente
en este documento y su debida justificación para no aplicarlo en el proyecto:
Modelo de procesos Justificación
Es un modelo de procesos limitado, si se generan

cambios en el proyecto puede generar un retrabajo de
todo el proyecto, el cliente no conoce los avances del
Modelo en cascada
proyecto hasta el final lo que puede generar cambios
en un futuro y para solventarlos se debe realizar el
mismo proceso del modelo en cascada.
Al pertenecer a una metodología tradicional se basa

mucho en la documentación y una exhaustiva
planeación al principio ya que, si no se cuenta con ella,
la estimación del costo del proyecto será difícil, además,
Modelo de procesos incremental
se pueden realizar cambios, pero en algunas ocasiones
la comunicación con el cliente no es clara o no se llega a
un acuerdo y se puede quedar estancado en un cambio
perdiendo tiempo.
Este modelo de procesos requiere de gestores

experimentales para encontrar y mitigar los errores.
Modelo de procesos espiral Existe una complicación cuando se evalúan los riesgos
ya que se requiere la participación continua por parte del
cliente y se pierde tiempo cuando se vuelven a producir
una especificación completa de los requisitos.
Cuenta con una dificultad para documentar, debido a
que se trabaja de forma rápida y con cambios
Extreme programming
constantes es difícil llevar un historial de lo que se ha
hecho.
Se debe conocer cada una de las metodologías Crystal,

debido a que son una familia entera de metodologías,
una vez conocidas se debe elegir la que más se adapte
Crystal methodologies al proyecto, esto para nosotros es una búsqueda doble,
una para conocer las metodologías, otra para conocer
su familia de metodologías y finalmente elegir una.
Se quiere entregar un producto de calidad, pero esta

metodología tiene una desventaja de que al momento
ASD de entregar un producto de alta calidad se prolonga
cuando un ciclo se atrasa por errores y/o cambios que
no fueron detectados anteriormente.
La principal desventaja que se encontró fue el hecho de

que cada miembro debe conocer y estar entrenado en
TSP el PSP (Personal Software Process), además de que
se debe contar con un buen conjunto de métricas y
parámetros de calidad.

lOMoA
El tamaño del proyecto no es óptimo para usarlo con

este modelo, SCRUM está diseñado para abarcar
Scrum
proyectos de gran tamaño, además de la cantidad de
roles con los que cuenta su proceso.
Fuente: Elaboración propia

lOMoA
Actividades, roles y tiempos
Teniendo en cuenta la metodología escogida (DSDM) se consultaron los roles y
etapas de un proyecto.
El manejo de roles que se tendrán son los siguientes:
• Team leader (María Fernanda Barrero Rincón): Dicho miembro fue elegido en el
equipo y se encargará de:
o Generar reuniones entre el equipo para evidenciar el avance del proyecto.
o Reunirse con el cliente para mostrar los avances con cada Evolutionary
Development.
o Dar la retroalimentación hecha por el cliente al equipo.
o Desarrollar junto al equipo diversas tareas de desarrollo, tales como: FrontEnd e
integración con el BackEnd.
• Solution developer (Yesid Fernando Amaya Porras): Se encargará de:
o Transformar los requisitos en la solución que cumpla con las necesidades
planteadas.
o Organizar y dividir las tareas de desarrollo a cada miembro del equipo.
o Revisar que los tiempos de las tareas de desarrollo se estén cumpliendo.
o Desarrollar junto al equipo diversas tareas de desarrollo, tales como: FrontEnd e
integración con el BackEnd.
• Solution tester (Jhonathan Artunduaga Almario): Se encargará de:
o Asegurar la calidad del desarrollo de software realizando el QA a cada de las
actividades previamente desarrolladas en su totalidad, es decir: FrontEnd,
BackEnd e integración de los mismos.
o Desarrollar junto al equipo diversas tareas de desarrollos, tales como: BackEnd,
e integración del FrontEnd con el BackEnd.

lOMoA
• Technical advisor (Edinson Balaguera Rodriguez): Se encargará de:
o Montar el ambiente de desarrollo, el cual contará con: Ambiente de QA y
ambiente de producción.
o Desarrollar junto al equipo diversas tareas de desarrollo, tales como: Backend e
integración del FrontEnd con el BackEnd.
o Realizar los respectivos despliegues a QA en la etapa de Deployment, con los
cambios previamente aprobados por el Solution Tester.
o Realizar el despliegue a producción con la versión final aprobada por el cliente.
o Realizar el despliegue de los diferentes cambios que se realicen en la etapa de
Post-Project.
Aunque DSDM tiene más roles, se ha consultado sobre ellos y como equipo se tomó la
decisión de definir 4 roles donde cada uno cumplirá la responsabilidad que lleve a cabo ese
rol.
Siguiendo con las actividades y tiempos a realizar, se utilizó la herramienta Gantt
Project para el desarrollo del diagrama teniendo en cuenta cada fase de un proyecto usando
la metodología DSDM, listando los responsables de estas y su respectivo rol.
El documento se adjunta como un anexo con nombre “Plan de proyecto.pdf”.

lOMoA
Requerimientos del proyecto
Requerimientos funcionales
Requerimientos Funcionales
Requerimiento Actores
Cod Descripción de requisito información
funcional Involucrados
El sistema permitirá registrar una cuenta para el
usuario que requiera un servicio, los datos que
Administrador, debe registrar son:
El sistema permitirá
Profesional de
RF1 el registro de Nombre completo, tipo de documento, número
la salud.
usuarios de documento, rol (administrador, usuario y/o
Usuario
profesional de la salud), edad, género, teléfono,
dirección, correo electrónico
Administrador, El usuario deberá ingresar el correo y

El sistema permitirá Profesional de contraseña y posteriormente darle clic al botón
RF2
iniciar de sesión la salud. iniciar sesión. El sistema validará el correo y
Usuario contraseña
El sistema debe permitir al usuario buscar al
al usuario consultar
RF3 Usuario profesional de la salud por medio de su nombre,
profesional de la
y tipo de servicio.
salud
al usuario consultar El sistema debe permitir al usuario consultar una
RF4 la agenda del Usuario cita mediante la búsqueda en la sección de
profesional de la agenda del profesional de la salud elegido
salud.
El sistema debe permitir agendar una sesión
RF5 reservar una sesión Usuario
disponible, elegida por el usuario.
disponible
El sistema permitirá El sistema debe permitir al usuario dar clic en

RF6 realizar pagos en Usuario agendar y redireccionar al método de pago y
línea haber efectuado la reserva exitosamente
El sistema debe permitir al usuario modificar

hora y fecha según la disponibilidad del
RF7 modificar fecha y Usuario
profesional de la salud, así como la cancelación
hora de reserva
de esta.
El sistema permitirá El sistema deberá permitir al usuario validar su

Usuario /
RF8 la validación de reserva para no permitir más de una en un
Sistema
reservas periodo de 24 horas.
El sistema permitirá El sistema deberá permitir al profesional de la

Profesional de
RF9 las consultas de salud revisar su agenda para validar las citas
la salud
reservas reservadas por el usuario.

lOMoA
El sistema permitirá El sistema deberá permitir al profesional de la

Profesional de
RF10 la consulta de salud validar la información del usuario que
la salud
usuarios. realizo la reserva.
El sistema permitirá El sistema deberá permitir al administrador

RF11 generar reportes de Administrador poder generar y descargar los reportes de los
los profesionales profesionales registrados

RF12 generar reportes de Administrador generar y descargar de todos los usuarios que
los usuarios se encuentren registrados en la plataforma.
El sistema deberá permitir al administrador
consultar la agenda
RF13 Administrador visualizar las agendas de los profesionales
de cualquier
registrados
profesional
El sistema deberá permitir al administrador
consultar la agenda
RF14 Administrador visualizar las agendas de los usuarios
de cualquier
registrados
usuario.

RF15 consultar los Administrador generar reportes de los servicios más
servicios ofrecidos solicitados por los usuarios.
Requerimientos no funcionales
Código RNF 001
Nombre Compatibilidad
Descripción La plataforma deberá ser compatible con todos los navegadores

más usados, herramientas para una interfaz agradable.
Prioridad Alta
Código RNF 002
Nombre Almacenamiento
Descripción El almacenamiento de la aplicación estará ubicado en una nube,

debido a su soporte de datos.
Prioridad Alta
Código RNF 003
Nombre Usabilidad

lOMoA
Descripción El sistema contará con una interfaz agradable y fácil de entender,

permitiendo que cualquier persona con un mínimo de
conocimiento en tecnología pueda usarlo correctamente.
Prioridad Alta
Código RNF 004
Nombre Disponibilidad
Descripción El sistema estará disponible las 24 horas del día, los 7 días de la
semana siempre y cuando se tenga conexión a internet.
Prioridad Alta
Código RNF 005
Nombre Conexión
Descripción El ordenador deberá contar con conexión a internet para usar

todas sus características y funcionalidades.
Prioridad Alta
Código RNF 006
Nombre Accesibilidad
Descripción La aplicación contará con un sistema de seguridad por contraseña

de usuario a la hora de iniciar la sesión. También contará con inicio
de sesión con Google.
Contará con un perfil de super administrador que será el
encargado de controlar el flujo de datos entre la base de datos y
la capa de muestra del aplicativo.
Prioridad Alta
Código RNF 007
Nombre Idioma
Descripción Usará por defecto el idioma español (Latinoamérica)
Prioridad Alta
Código RNF 008

lOMoA
Nombre Escalabilidad
Descripción El sistema será diseñado de tal forma que tendrá la capacidad de

ser adaptativo a los cambios que se puedan presentar.
Prioridad Alta
Código RNF 009
Nombre Seguridad
Descripción La información sensible será guardada de manera encriptada, el

acceso al sistema solo será posible si se encuentra registrado en
el sistema.
Prioridad Alta

lOMoA
Casos de uso
MÓDULO Login
ID CDU_1
Nombre caso de Ingreso al sistema.
uso
Objetivo Validar el ingreso al sistema con usuario y contraseña.
Actores Administrador, Profesional de la salud, Usuario.
• Se debe estar registrado en el sistema.
Precondiciones
• Conexión a internet.
• El sistema identifica el tipo de usuario.
Postcondiciones • El sistema permite el ingreso del usuario solo cuando este se
encuentra registrado.
Actor Sistema
1. El actor ingresa a la 2. El sistema pedirá usuario y
dirección Web. contraseña.
Flujo Principal 3. El actor ingresa usuario y 4. El sistema permitirá el
contraseña anteriormente ingreso si el usuario y
registrado en el sistema. contraseña es válido
3. El actor ingresa usuario y 4. El sistema no permitirá el

Flujo Alternativo contraseña no registrados ingreso del actor.
en el sistema.
MÓDULO Registro de Usuarios.

ID CDU_2
Nombre caso de Registro de profesionales de la salud.
uso
Objetivo Registrar un usuario Profesional de la salud en el sistema.
Actores Profesional de la salud.
Precondiciones • Ser profesional de la salud autorizado para registrar su usuario.
• No tener un usuario registrado en el sistema.
• El sistema permite el ingreso de la información del profesional de
Postcondiciones la salud.
• Registro del nuevo usuario tipo profesional de la salud.
Actor Sistema
1. El actor ingresara a la 2. El sistema pedirá los

dirección web. siguientes datos al actor:
3. El actor ingresara los • Nombre completo.
datos solicitados. • Tipo de servicio que
ofrece.
Flujo Principal
• Dirección
• Costos de los servicios
que ofrece.
• Horario y la agenda que
ofrece.
• Tiempo de una sesión de
su servicio.

lOMoA
• Si puede atender varios

usuarios a la vez o no.
• Identificación como
personas natural o jurídica
si es necesario.
• Usuario y contraseña para
ingreso al sistema.
4. El sistema guarda la
información ingresada.
Flujo Alternativo 1. Si el actor no es autorizado para registrarse, no se debe permitir el

ingreso a la dirección Web.
MÓDULO Registro de Usuarios.

ID CDU_3
Nombre caso de Registro de usuario.
uso
Objetivo Registrar un usuario paciente en el sistema.
Actores Usuario.
Precondiciones
• No tener un usuario registrado en el sistema.
• El sistema permite el ingreso de la información del paciente.
Postcondiciones
• Registro del nuevo usuario tipo paciente.
Actor Sistema
1. El actor ingresara a la 2. El sistema pedirá los
dirección web. siguientes datos al actor:
3. El actor ingresara los datos • Nombre completo.
solicitados. • Género.
Flujo Principal • Edad.
• Dirección de residencia.
• Correo electrónico.
• Usuario y Contraseña.
4. El sistema guarda la
información ingresada.
Flujo Alternativo No aplica
MÓDULO Usuario - Consulta

ID CDU_4
Nombre caso de Consultar Profesional de la salud.
uso
Consultar profesional de la salud por nombre, tipo de servicio y
Objetivo
ubicación.
Actores Usuario
Precondiciones
• Estar registrado en el sistema.
Postcondiciones • El sistema muestra el resultado de la búsqueda.
Actor Sistemas
Flujo Principal 1. El actor ingresa al sistema 2. El sistema carga el módulo
con usuario y contraseña. para usuarios.

lOMoA
3. El actor realiza búsqueda 4. El sistema arroja el

del profesional de la salud. resultado de la búsqueda.
Flujo Alternativo 4. Cuando la búsqueda no arroje ningún resultado el sistema informara de

ello.
MÓDULO Usuario - Consulta

ID CDU_5
Nombre caso de Consultar la agenda del profesional de la salud.
uso
Objetivo Seleccionar un profesional de la salud y consultar su agenda.
Actores Usuario
Precondiciones • Estar registrado en el sistema.
• Realizar caso de uso CDU_4
• El sistema muestra la agenda del profesional de la salud
Postcondiciones
seleccionado.
Actor Sistema
1. El actor ingresa al sistema 2. El sistema carga el módulo
con usuario y contraseña. para usuarios.
Flujo Principal
5. El actor selecciona el 6. El sistema muestra la
profesional de la salud. agenda el profesional de la
salud.
Flujo Alternativo No aplica.
MÓDULO Usuario - Reserva

ID CDU_6
Nombre caso de Reservar una sesión disponible.
uso
Seleccionar una sesión disponible en la agenda del profesional de la
Objetivo
salud y reservarla.
Actores Usuario
• Realizar caso de uso CDU_4 y CDU_5
• El sistema permitirá reservar una sesión disponible de la
Postcondiciones
agenda del profesional de la salud.
Actor Sistema
1. El actor ingresa al sistema 2. El sistema carga el
con usuario y contraseña. módulo para usuarios.
Flujo Principal profesional de la salud. agenda el profesional de
7. El actor selecciona y la salud.
reserva una sesión 8. El sistema realizara la
disponible de la agenda reserva de la sesión.
del profesional de la salud.

lOMoA
MÓDULO Usuario – Pagos

ID CDU_7
Nombre caso de uso Pago de sesión reservada.
Objetivo Hacer el pago en línea de la sesión reservada.
Actores Usuario.
• Realizar caso de uso CDU_4, CDU_5 y CDU_6
• El sistema permitirá realizar el pago de la sesión reservada a
Postcondiciones través de distintas formas de pago (pse, tarjeta crédito, tarjeta
debito…)
Actor Sistema

profesional de la salud. agenda el profesional de
Flujo Principal reserva una sesión 7. El sistema realizara la
disponible de la agenda reserva de la sesión.
del profesional de la 8. El sistema pedirá
salud. confirmación o agregar
9. El actor confirma la una nueva reserva.
reserva de la sesión. 10. El sistema abre el módulo
11. El actor realizara el pago de pagos.
a través de una de las
opciones disponibles.
8. El sistema pedirá confirmación o agregar una nueva reserva.

9. El actor confirma agregar una nueva reserva.
Flujo Alternativo 10. El sistema se dirigirá al módulo de reserva.
11. Se repiten los pasos a partir del punto 3.
MÓDULO Usuario – Sesiones reservadas

ID CDU_8
Nombre caso de uso Modificar fecha y hora de sesión.
Objetivo Modificar la fecha y hora de una sesión reservada y paga.
Actores Usuario
• Realizar caso de uso CDU_4, CDU_5, CDU_6 y CDU_7
• El sistema permitirá la modificación de la fecha y hora de la
Postcondiciones
sesión reservada.
Flujo Principal Actor Sistema

lOMoA

3. El actor se dirige al 4. El sistema muestra las
módulo de sesiones sesiones reservadas.
reservadas. 6. El sistema pedirá
5. El actor escoge la sesión confirmación de
reservada, opción modificación y validara si
modificar. es posible hacer el
7. El actor modifica la fecha y cambio.
hora de la reserva. 8. El sistema pedirá
nuevamente confirmación.
9. El sistema actualizara la
fecha y hora de reserva.
1. No es posible realizar el cambio de fecha.
Flujo Alternativo 2. El sistema informa que el cambio de fecha no es posible ya que
no se cumple con el plazo máximo.
MÓDULO Usuario - Reserva

ID CDU_9
Nombre caso de uso Validación de fechas de reserva.
Validar que no se pueda realizar más de una reserva en la misma fecha y
Objetivo
hora.
Actores Usuario
• Realizar caso de uso CDU_4, CDU_5 y CDU_6
• El sistema no permitirá que se realice más de una reserva en la
Postcondiciones
misma fecha y hora.
Actor Sistema
del profesional de la salud. resultado de la búsqueda
profesional de la salud. agenda el profesional de
reserva una sesión 8. El sistema pedirá
Flujo Principal disponible de la agenda confirmación o agregar
del profesional de la una nueva reserva.
salud. 10. El sistema se dirigirá al
9. El actor confirma agregar módulo de reserva.
una nueva reserva. 12. El sistema validara que la
11. El actor realizara los nueva reserva no se cruce
pasos 3 al 7. con una ya existente.
13. Si las reservas se cruzan
el sistema no permitirá
realizar la nueva reserva.
Flujo Alternativo 14. Si las reservas no se cruzan el sistema realizara la nueva

reserva.

lOMoA
MÓDULO Proveedores
ID CDU_10
Nombre caso de uso Consultar sesiones agendadas.
Objetivo Consultar las sesiones que tiene agendadas el profesional de la salud.
Actores Profesional de la salud.
Precondiciones
• El sistema permitirá al actor, realizar la consulta de las
Postcondiciones
sesiones que tiene agendadas.
Actor Sistema
con usuario y contraseña. módulo para proveedores.
Flujo Principal 3. El actor ingresa a la opción 4. El sistema muestra las
consultar sesiones sesiones agendadas por
agendadas. fecha.
MÓDULO Proveedores
ID CDU_11
Nombre caso de uso Consulta de usuarios
Objetivo Consultar la información de los usuarios que han agendado sesión.
Actores Profesionales de salud.
Precondiciones
• El sistema permitirá consultar los datos de los usuarios que
Postcondiciones
agenda la sesión.
Actor Sistema
con usuario y contraseña. módulo para proveedores.
3. El actor ingresa a la opción 4. El sistema muestra las
consultar sesiones sesiones agendadas por
agendadas. fecha.
5. El actor ingresa a la 6. El sistema mostrara los
Flujo Principal sesión agendada. siguientes datos del
usuario que ha agendado
la sesión.
a. Nombre completo
b. Género.
c. Edad
d. Correo
electrónico.
MÓDULO Reportes
ID CDU_12
Nombre caso de uso Reportes profesionales de la salud.
Generar reporte de los profesionales de la salud que se encuentran
Objetivo
registrados en el sistema.
Actores Administrador

lOMoA
Precondiciones
• El sistema genera el reporte de los profesionales de la salud
Postcondiciones
registrados en el sistema.
Actor Sistema
con usuario y contraseña. módulo para
Flujo Principal 3. El actor selecciona la administradores.
opción reportes. 5. El sistema genera el
4. El actor selecciona la reporte de los
opción Reportes por profesionales registrados
profesionales de la salud. en la plataforma.
MÓDULO Reportes
ID CDU_13
Nombre caso de uso Reporte de usuarios registrados
Objetivo Generar reporte de los usuarios registrados en el sistema.
Actores Administrador.
Precondiciones
Postcondiciones • El sistema genera el reporte de los usuarios registrados.
Actor Sistema
3. El actor selecciona la administradores.
Flujo Principal opción reportes. 5. El sistema genera el
4. El actor selecciona la reporte de los usuarios
opción Reportes por registrados en la
profesionales de la salud. plataforma.
MÓDULO Consultas
ID CDU_14
Nombre caso de uso Consulta de agenda de los profesionales de la salud.
Objetivo Consultar la agenda de un profesional de la salud.
Precondiciones
• El sistema permitirá consultar la agenda de los profesionales de
Postcondiciones
la salud.
Actor Sistema
Flujo Principal 3. El actor selecciona la administradores.
opción consultas. 6. El sistema arroja como
4. El actor selecciona la resultado la agenda del
opción consulta por profesional de la salud
profesionales de la salud. consultado.

lOMoA
5. El actor realiza la
búsqueda de un
profesional de la salud.
MÓDULO Consultas
ID CDU_15
Nombre caso de uso Consulta agenda de un usuario.
Precondiciones
Postcondiciones • El sistema permitirá consultar la agenda de los usuarios.
Actor Sistema
Flujo Principal 4. El actor selecciona la resultado la agenda del
opción consulta por usuario consultado.
usuario.
búsqueda de un usuario.
MÓDULO Consultas
ID CDU_16
Nombre caso de uso Consulta agenda de un profesional.
Precondiciones
Postcondiciones • El sistema permitirá consultar la agenda de los usuarios.
Actor Sistema
4. El actor selecciona la resultado la agenda del
Flujo Principal
opción consulta por profesional consultado.
profesional.
búsqueda de un
profesional.
MÓDULO Consultas
ID CDU_17

lOMoA
Nombre caso de uso Consulta de servicio.

Objetivo Consultar los servicios más solicitados.
Precondiciones
• El sistema permitirá consultar los servicios más solicitados por
Postcondiciones
los usuarios.
Actor Sistema
Flujo Principal
4. El actor selecciona la resultado los servicios y el
opción consulta de orden de demanda de
servicios. estos, de mayor a menor.

lOMoA
Diagrama de clases

lOMoA
Diagramas de Secuencia
Consultar Profesional
Registrar Profesional

lOMoA
Modificar Reserva

lOMoA

lOMoA
Diagramas de estado
Diagrama de estado reserva
Diagrama de estado reportes:

lOMoA

lOMoA
Link de la sustentación
Para acceder al link haga clic aquí.

lOMoA
Referencias
"Guía Normas APA Séptima 7.ª Edición 2020" (2020). Recursos bibliográficos.
11. https://ciencia.lasalle.edu.co/recursos_bibliograficos/11
Normas APA – 7ma (séptima) edición. (2021, 22 enero). APA. https://normas-apa.org/
Tinoco, O., Rosales, P., & Salas, J. (2010). Criterios de selección de metodologías
de desarrollo de software (2.a ed., Vol. 13).
https://www.redalyc.org/pdf/816/81619984009.pdf
Colaboradores de Wikipedia. (2020, 23 mayo). Team Software Process. Wikipedia, la
enciclopedia libre.
https://es.wikipedia.org/wiki/Team_Software_Process
Kniberg, H. (2007). SCRUM Y XP DESDE LAS TRINCHERAS Cómo hacemos Scrum.
C4Media Inc. http://www.leanproduction.co/wp -content/uploads/2015/11/scrum-y-xp-
desde-las-trincheras.pdf
J. (2010, 15 enero). El primer método ágil, DSDM. Javier Garzas.
https://www.javiergarzas.com/2010/01/primer -metodo-agil-
dsdm.html#:%7E:text=RAD%20son%20las%20siglas%20de,(Computer%20Aided%20S
oftware%20Engineering)
Teixeira, D., Afonso, F., Gaiolas de Sousa, J., & Pereira, T. (s. f.). DSDM – Dynamic Systems
Development Methodology. https://www.researchgate.net/profile/Daniel -Teixeira-
16/publication/237612979_DSDM_ -
_Dynamic_Systems_Development_Methodology/links/55ae197c08aed9b7dcdb2a0e/DS
DM-Dynamic-Systems-Development-Methodology.pdf

lOMoA
Anwer, F., Aftab, S., Waheed, U., & Muhammad, S. (2017). Agile Software Development
Models TDD, FDD, DSDM, and Crystal Methods: A Survey (2.a ed., Vol. 8).
https://www.researchgate.net/profile/Shabib_Aftab/publication/316273992_Agile_Softw
re_Development_Models_TDD_FDD_DSDM_and_Crystal_Methods_A_Survey/links/58f
86bc44585158d8a6c4f11/Agile-Software-Development-Models-TDD-FDD-DSDM-and-
Crystal-Methods-A-Survey.pdf
Navarro, A., Fernández, J. D., & Morales, J. (2013). Revisión de metodologías ágiles para
el desarrollo de software (2.a ed., Vol. 11). PROSPECTIVA.
https://www.redalyc.org/pdf/4962/496250736004.pdf
Figueroa, R. G., Solís, C. J., & Cabrera, A. A. (2008). Metodologías tradicionales vs.
metodologías ágiles. Universidad Técnica Particular de Loja, Escuela de Ciencias de
la Computación, 9.
Dynamic Systems Development Method - Wikiversidad. (s. f.). Wikiuniversidad. Recuperado
6 de marzo de 2021, de
https://es.wikiversity.org/wiki/Dynamic_Systems_Development_Method#:%7E:text=El%2
0modelo%20DSDM%20consta%20de,software%2C%20y%20Post%2DProyecto .
El ciclo de vida de un proyecto con DSDM Agile Project... (2019, 13 noviembre). Netmind.
https://www.netmind.es/knowledge -center/el-ciclo-de-vida-de-un-proyecto-con-dsdm-
agile-project-framework/
Métodos de Desarrollo de Sistemas Dinámicos (DSDM). (2015, 5 abril). Ingeniería del Software
UAH. https://ingenieriadelsoftwareuah2015.wordpress.com/2015/03/29/metodos-de-
desarrollo-de-sistemas-dinamicos-dsdm/
Luna, E. (2014, 11 marzo). Fases del DSDM. dsdm.
https://metodologiadsdm.wordpress.com/2014/03/11/fases -del-
dsdm/

lOMoA
A. (2020, 20 octubre). Roles y responsabilidades DSDM Agile Project... Netmind.
https://www.netmind.es/knowledge -center/roles-y-responsabilidades-en-el-dsdm-agile-
project-framework/
agilebusiness.org. (s. f.). Agile bussiness. Recuperado 9 de marzo de 2021, de
https://www.agilebusiness.org/page/ProjectFramework_07_RolesResponsibilities
▷ Diagrama de clases. Teoria y ejemplos. (2020, 22 noviembre). DiagramasUML.com.
https://diagramasuml.com/diagrama -de-clases/
J. (2019, 20 abril). Recursos en GanttProject. El equipo de tu proyecto. Jorge Saiz.
https://jorgesaiz.com/blog/recursos-en-
ganttproject/#:%7E:text=Los%20recursos%20en%20GanttProject&text=Por%20defecto%20se
%20visualiza%20la,a%20trav%C3%A9s%20del%20men%C3%BA%20correspondiente .

Entrega Final Semana 7

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Entrega Final Semana 7

Cargado por

Copyright:

Formatos disponibles

lOMoARcPSD|15259203

Entrega Final semana 7

Ingeniería de Software I (Politécnico Grancolombiano)

Studocu no está patrocinado ni avalado por ningún colegio o universidad.

Entrega Final Ingeniería de Software 1

María Fernanda Barrero Rincón

Yesid Fernando Amaya Porras

Jhonathan Artunduaga Almario

Edinson Balaguera Rodríguez

Facultad de Ingeniería, Diseño e Innovación, Institución Universitaria Politécnico

Grupo 3 - Ingeniería de Software 1

Wilson Manuel Mantilla Velasco

Descargado por Edison Andres Rojas Angarita

En el presente documento se pretende exponer las características, ventajas y

desventajas de cada tipo de metodología de desarrollo de software e identificar la que mejor

se adapte a un sistema de agendamiento de citas médicas e implementarla según las

necesidades del cliente.

El éxito de un proyecto de software se define gracias a una gestión correcta de

Las metodologías tradicionales y ágiles ofrecen diversos modelos de procesos,

diferenciar cada uno de ellos y conocer cómo aplicarlos al desarrollo de un proyecto de

software marcará una diferencia entre el éxito y el fracaso de dicho proyecto.

Para lograr discrepar cada uno de ellos, es necesaria la investigación teniendo

en cuenta su definición, ventajas, desventajas y finalmente, una comparación de estos

Descargado por Edison Andres Rojas Angarita

Generar la documentación para desarrollar un software que permita el registro

de profesionales de la salud para ofrecer agenda de sus servicios.

1. Consultar y escoger la metodología que más se adapte al desarrollo del software.

3. Diseñar los diagramas de actividades, diagramas de estado y el diagrama de clases.

Descargado por Edison Andres Rojas Angarita

determinado, se inicia con el ciclo del desarrollo de un producto de software, además, se

Otra característica fundamental es el alto costo que tiene el implementar cambios, no

gran probabilidad de sufrir cambios de requerimientos durante el desarrollo.

Dentro de las metodologías tradicionales se encuentran los siguientes modelos

• Modelo De Procesos Incremental.

• Modelo De Procesos Espiral.

Mientras que, las metodologías tradicionales enfatizan en la especificación de todo

antes de comenzar el desarrollo, las metodologías ágiles hacen énfasis en obtener

resultados satisfactorios para el cliente y la capacidad de respuesta a un cambio dentro del

Las metodologías ágiles nacen gracias al manifiesto ágil.

Dentro de las metodologías ágiles se encuentran los siguientes modelos de procesos:

• Desarrollo adaptativo de software.

Descargado por Edison Andres Rojas Angarita

• Team Software Process.

• Método De Desarrollo De Sistemas Dinámicos (DSDM).

Descargado por Edison Andres Rojas Angarita

Diferencias entre metodologías

Canós, J. (2005) resume las características de ambas metodologías, en la siguiente

Metodologías ágiles Metodologías tradicionales

Se basan en heurísticas provenientes de prácticas de Se basan en normas provenientes de estándares

A parte de las características de cada metodología con respecto a la otra, en

Metodología tradicional Etapa Metodología ágil

Análisis de requisitos Planificación adaptativa: Entregas

Descargado por Edison Andres Rojas Angarita

Modelo de procesos para abordar el proyecto: DSDM

El modelo de procesos elegido para abordar el proyecto es DSDM, perteneciente a

El DSDM cuenta con las siguientes características:

1. Participación del usuario para ser más eficaces y precisos en el desarrollo

2. El desarrollo es iterativo e incremental permitiendo la realización de cambios

no previstos durante el desarrollo del proyecto.

5. Se integran pruebas en cada fase para evitar costes a futuro.

6. El equipo puede realizar cambios importantes sin esperar la autorización de

Resaltando las características 1, 4 y 6 para tomar la elección de esta metodología,