Facultad de Ingeniería, Diseño e Innovación

Ingeniería de software 1

Trabajo colaborativo

Entrega 2 Semana 5

Politecnico Grancolombiano

Ing. Software 1

Bogotá DC

Abril del 2022

 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

Introducción

Con cada iteración alrededor de la espiral, se crean sucesivas versiones del software, cada vez más

completas y, al final, el sistema de software ya queda totalmente funcional.

La diferencia principal entre el modelo espiral y los modelos anteriores (ej.: cascada, evolutivo,

incremental, etc.) es la evaluación del riesgo. El riesgo es todo lo que pueda salir mal en un

proyecto de desarrollo de software. Por ejemplo, si queremos utilizar un lenguaje de programación

para desarrollar un sistema operativo, un riesgo posible es que los compiladores utilizables no

produzcan un código objeto eficiente. Los riesgos originan problemas en el proyecto, como el

exceso de los costos. Es así como, la disminución de los riesgos es una actividad muy importante.

Ingeniería de software es la aplicación de enfoques sistemáticos y disciplinados al desarrollo de

software, para esto se han creado modelos y metodologías para la correcta utilización del tiempo

y recursos que una empresa o entidad disponen.

Los modelos de desarrollo de software ofrecen un marco de trabajo usado para controlar el proceso

de desarrollo de sistemas de información, estos marcos de trabajo consisten en una filosofía de

desarrollo de programas la cual debe de contar con las herramientas necesarias para la asistencia

del proceso de desarrollo.

En el siguiente proyecto encontraremos un modelo de software que tomaremos como base

para la construcción de un producto que será utilizado por una compañía prestadora de servicios

de salud, el cliente nos solicita un programa en el cual se pueda tener acceso a una base de datos
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

ordenada tanto para sus clientes como para sus profesionales, manejaremos conceptos y

herramientas que nos ayudaran a una acertada toma de decisiones teniendo claras las necesidades

y requerimientos del cliente y definiendo el mejor modelo de desarrollo con sus fases previas a la

construcción de software.
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

• Parte 1.

La propuesta inicial para el desarrollo es:

• Crear base de datos con dos tablas, una denominada Usuarios y la otra Profesionales, que cada una
cuente con permisos tanto de ingreso como de retiro
• En la base de datos de los usuarios deben contener la información mínima de cada persona como
Nombre, edad, teléfono, email, género y demás datos complementarios según el rol.
• En la base de datos de los profesionales deben contener la información mínima de cada profesional
como Nombre, edad, email, teléfono, costos, especialidad, si es persona natural o jurídica y demás
datos complementarios según el rol.
• Crear un acceso a la plataforma con un login donde se solicita usuario y contraseña.
• Generar una opción de visualizar la agenda y disponibilidad de los profesionales, que tenga un
contador de citas ocupadas y disponibles.
• Crear una opción de cancelar o reubicar citas para los usuarios y profesionales.
• Incluir un botón de pago para que los usuarios puedan pagar sus citas desde la plataforma.
• El Software es en línea para que los usuarios puedan cancelar y agendar, gracias a que todo se
sincroniza automáticamente.
• Implementar una herramienta en la cual combine toda la información de su paciente en un solo
historial de pacientes para acceder fácilmente a los datos en cualquier momento.

Para el desarrollo de nuestro software escogimos el modelo espiral que básicamente consiste en
una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro. Se suele
interpretar como que dentro de cada ciclo de la espiral se sigue un Modelo Cascada, pero no
necesariamente debe ser así. El Espiral puede verse como un modelo evolutivo que conjuga la
naturaleza iterativa del modelo MCP con los aspectos controlados y sistemáticos del Modelo
Cascada, con el agregado de gestión de riesgo.
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

En cada vuelta o iteración hay que tener en cuenta:

• Los Objetivos: qué necesidad debe cubrir el producto.

• Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes
puntos de vista como pueden ser:

Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos
fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y
habilidad para detectar y catalogar correctamente los riesgos.

Las actividades para realizar son:

• Levantamiento de requerimientos.
• Diseño y elaboración de casos de uso.
• Diseño y elaboración de diagramas de secuencia.
• Diagrama de Clases.
• Elaboración de modelo Entidad-Relación.
• Crear base de datos.
• Desarrollo de casos de uso.
• Pruebas.
• Despliegue.
• Mantenimiento.
• Pruebas.
• Aprobación

Roles:
La metodología que escogimos es de trabajo ágil denominada Scrum es un proceso en el que se
aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en
equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras
y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio
que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos
en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y

la productividad son fundamentales.

• Product Owner: Se encarga de obtener el máximo valor posible al mínimo costo. También es el
responsable de la cartera de productos, conocida como pila de producto o Product Backlog. Por
esta razón, comprende las necesidades de los usuarios dentro del negocio.
• Scrum Team: está compuesto por un Product Owner, el equipo de desarrollo y un Scrum Master.
Es decir, se llama Scrum Team a aquellos equipos donde se pueden encontrar los tres roles.
• Scrum Master: Tiene dos funciones principales dentro del marco de trabajo: gestionar el
proceso Scrum y ayudar a eliminar impedimentos que puedan afectar a la entrega del producto.
Además, se encarga de las labores de mentoring y formación, coaching y de facilitar reuniones y
eventos si es necesario.
• Development Team: todos los miembros del equipo son “desarrolladores”, escriban o no código.
Además de escribir código, los grandes Development Teams realizan otras muchas actividades
(que involucran otras áreas de conocimiento) de gran valor para el Producto.
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

• Arquitecto de software: diseñan y desarrollan sistemas y aplicaciones de software. Pueden

crear software a medida para clientes o productos orientados a consumidores, como juegos o
aplicaciones.
• DBA: Es el responsable por la Administración de las Bases de Datos. Administra las tecnologías
de la información y la comunicación, siendo responsable de los aspectos técnicos, tecnológicos,
científicos, inteligencia de negocios y legales de bases de datos.
• QA: informática viene de las siglas en inglés Quality Assurance, algo que en español significa algo
así como “asegurar la calidad”. Como su propio nombre indica, consiste en asegurar que el
producto final sea de calidad, es decir, que satisfaga las necesidades del cliente y que no tenga
ningún error.
• Desarrollador de Software: es un especialista en informática que es capaz de concebir y
elaborar sistemas informáticos (paquetes de software), así como de implementarlos y ponerlos a
punto, utilizando uno o varios lenguajes de programación.
Identificados los roles se divide el trabajo así:
Rol Actividad
Product Owner: Levantamiento de requerimientos
Arquitecto de Software Diseño y elaboración de casos de uso
Arquitecto de Software Diseño y elaboración de diagramas de secuencia
Arquitecto de Software Diagrama de Clases
Arquitecto de Software Elaboración de modelo Entidad-Relación
DBA Crear base de datos
Desarrollador de Software Desarrollo de casos de uso
QA Pruebas
Desarrollador de Software Despliegue
Desarrollador de Software Mantenimiento
QA Pruebas
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

Scrum Team Aprobación

Estimación en tiempo del desarrollo de las actividades:

Sprint Descripción Tiempo Responsable

estimado

1 • Creación Modelo 01 de abril al • Arquitecto de Software

Entidad de Relación. 15 de abril 2022 • DBA
• Creación Base de
datos.

2 • Registrar usuario 16 de abril al • Desarrolladores

nuevo (Profesional 30 de abril 2022
proveedor o cliente) • Desarrolladores
• Consultar especialistas • QA
• Pruebas QA
3 • Asignación de cita 01 de mayo al • Desarrolladores
• pago de cita online • Desarrolladores
• Pruebas QA 15 de mayo 2022 • QA

4 • Modificar la fecha y 16 de mayo al • Desarrolladores

hora de la sesión.
• Registrar los servicios • Desarrolladores
31 de mayo 2021
que ofrece el
proveedor especialista
y la agenda que
dispone. • QA
• Pruebas QA

5 • Consultar las sesiones 01 junio al • Desarrolladores

que tiene agendadas el
proveedor especialista.
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

• Consulta la información 15 junio 2022

de los usuarios que han • Desarrolladores
solicitado sus servicios.
• Pruebas QA • QA

6 • Reporte de 16 de junio al • Desarrolladores

profesionales de la
salud registrados • Desarrolladores
30 junio 2022
• Reporte de usuarios
registrados.
• Pruebas QA • QA

7 • Agenda un profesional 01 julio al • Desarrolladores

específico
• Agenda de un usuario • Desarrolladores
30 julio 2022
específico.
• Consultar cuáles son • Desarrolladores
los servicios más
solicitados.
• Pruebas QA • QA
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

2. Parte 2.

Identificación de los requerimientos de su producto diferenciando los requerimientos funcionales

y no funcionales.

2.1 Requerimientos funcionales.

Definición: Los requerimientos funcionales definen qué hace el sistema, es decir, las funciones

que dicho sistema debe cumplir. En ese sentido este tipo de requerimientos son los que definen de

una manera detallada las funcionalidades concretas que el software debe contener con el fin de

permitir a los usuarios cumplir con sus labores.

• De las profesiones se debe conocer: nombre completo, tipo de servicio que ofrece,
dirección, costos de los servicios que ofrece, el horario y la agenda que ofrece que
incluye cuánto tiempo dura una sesión de su servicio y si puede atender varios usuarios a
la vez o no, identificación como personas natural y jurídica si es necesario.
• De los clientes se desea conocer: nombre completo, género, edad, dirección de residencia, correo
electrónico.
Cada cliente puede realizar las siguientes actividades:

➢ Buscar profesionales de la salud por nombre, tipo de servicio y ubicación.

➢ Seleccionar de un profesional y consultar su agenda.
➢ Seleccionar una sesión disponible y reservarla.
➢ Hacer el pago en línea de la sesión.
➢ Modificar la fecha y hora de la sesión.
➢ Un cliente no puede agendar más de una sesión a la vez.

Cada profesional proveedor debe poder:

▪ Registrar los servicios que ofrece y la agenda que dispone.

▪ Consultar las sesiones que tiene agendadas.
▪ Consulta la información de los usuarios que han solicitado sus servicios.
El sistema debe permitir generar consultas como las siguientes:
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

▪Reporte de profesionales de la salud registrados.

▪Reporte de usuarios registrados.
▪Agenda un profesional específico.
▪Agenda de un usuario específico.
▪Consultar cuáles son los servicios más solicitados.

2.1.2 Requerimientos no funcionales

Definición: Son aquellos requerimientos que no se refieren directamente a las funciones específicas

que entrega el sistema, sino a sus propiedades emergentes como la confiabilidad, disponibilidad,

tiempo de respuesta entre otros. Estas propiedades son también conocidas como los atributos de calidad

del sistema. De forma alternativa, definen las restricciones del sistema como la capacidad de los

dispositivos de entrada/salida y la representación de datos que se utiliza en la interface del sistema.

• Todos los usuarios deben tener una cuenta con login y contraseña e identificar si es un profesional
proveedor de servicios o un cliente. (restricción de acceso a personas no registradas).
• El Sistema debe almacenar la información de los profesionales proveedores y de los clientes.
• El sistema debe poder visualizarse en los sistemas operativos y navegadores acordados con el Equipo
de desarrollo y el cliente.
• El sistema debe tener un tiempo de respuesta acordado con el Equipo de desarrollo y el cliente.
• El sistema debe tener la posibilidad de que un usuario experto (Equipo de desarrollo) pueda realizar
ciertos cambios en su funcionalidad.

2.2 Especificación de los casos de uso correspondiente a los requerimientos funcionales

identificados en el punto anterior.

Caso de uso 01. Registrar usuario nuevo (Profesional proveedor o cliente)

Fuentes Product Owner que proporciono información de esta funcionalidad
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

Actor Usuarios (Profesional proveedor o cliente)

Descripción Permite a los usuarios registrarse en el sistema
1.El usuario nuevo ingresa al aplicativo.
2. El usuario nuevo elige la opción “registro de nuevos usuarios” y elige
una de las dos opciones proveedor profesional o cliente
3. El sistema le indica que debe ingresar la siguiente información:
3.1 Si es proveedor profesional
• Nombre completo
• Persona natural o jurídica
• Seleccione su tipo de identificación
• Número de identificación
• Correo electrónico
• Contraseña
• Tipo de servicio que ofrece
• Dirección
• Costos de los servicios que ofrece
Flujo • Horario de atención
• La agenda que ofrece que incluye
• Cuánto tiempo dura una sesión de su servicio
• Cuantos usuarios puede atender a la vez
3.2 Si es cliente
• Nombre completo
• Seleccione su tipo de identificación
• Número de identificación
• Correo electrónico
• Contraseña
• Género
• Fecha de nacimiento
• Dirección de residencia

4. El usuario elige la opción guardar cambios y crear usuario, el sistema

envía un correo electrónico con un link al que el usuario debe acceder para
validar el correo electrónico y crear satisfactoriamente un nuevo usuario.
Condición Inicial El usuario no de estar registrado en el sistema
Condición Final Usuario registrado en el sistema
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

Si al usuario registrar su número de documento este ya se encuentra

registrado, el sistema arrojara un mensaje indicando “el usuario y se
Nota:
encuentra registrado el sistema, si olvido su contraseña clic aquí” e iniciara
el proceso de recuperación por medio del correo electrónico

Caso de uso 02. Consultar especialistas

Fuentes Product Owner que proporciono información de esta funcionalidad
Actor Usuarios (clientes)
Descripción Permite a los usuarios consultar especialistas disponibles
• El usuario (cliente) registrado ingresa al sistema.
• El usuario (cliente) selecciona la opción ver especialistas.
Flujo
• El usuario selecciona el especialista de su interés, podrá visualizar todos sus
detalles (nombre, dirección, costo cita, duración cita, agenda disponible).

Condición Inicial El usuario (cliente) debe estar registrado en el sistema

Condición Final Visualización de especialistas

Caso de uso 03. Asignación de cita

Fuentes Product Owner que proporciono información de esta funcionalidad
Actor Usuarios (clientes)
Descripción Permite a los usuarios (clientes) programar una cita con un proveedor
especialista
Flujo • El usuario (cliente) registrado ingresa al sistema
• el usuario selecciona la opción ver especialistas
• El usuario selecciona el especialista de su interés, podrá visualizar todos sus
detalles (nombre, dirección, costo cita, duración cita, agenda disponible)
• El usuario selecciona uno de los espacios disponibles en la agenda del
especialista y elige la opción asignar cita. mensaje es enviado al correo
electrónico informando fecha y hora seleccionadas.
Condición Inicial El usuario (cliente) debe estar registrado en el sistema y no debe tener citas
asignadas
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

Condición Final Cita asignada

Caso de uso 04. pago de cita online

Fuentes Product Owner que proporciono información de esta
funcionalidad
Actor Usuarios (clientes)
Descripción Permite a los usuarios pagar citas asignadas
Flujo • El usuario (cliente) registrado ingresa al sistema
• el usuario selecciona la opción ver citas asignadas
• El usuario elige la opción pagar, luego la forma de
pago.
• El usuario es redireccionado para el portal de pagos
de su entidad bancaria seleccionada.
• Cuando se acredite el pago el soporte es enviado a
su correo electrónico y queda almacenado en el
sistema.
Condición Inicial El usuario (cliente) debe estar registrado en el
sistema tener citas asignadas
Condición Final Cita facturada y pagada

Caso de uso 05. Modificar la fecha y hora de la sesión.

Fuentes Product Owner que proporciono información de esta funcionalidad
Actor Usuarios (clientes)
Descripción Permite a los usuarios (clientes) modificar la fecha y hora de citas asignadas
Flujo • El usuario (cliente) registrado ingresa al sistema
• el usuario selecciona la opción ver citas asignadas
• El usuario elige la opción modificar la fecha y hora de citas asignadas
• El sistema muestra la disponibilidad de agenda del especialista con el cual el
usuario tenía la cita asignada.
• El usuario elige una nueva programación
• El sistema muestra mensaje de confirmación.
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

• Un mensaje con la nueva programación es enviado al correo electrónico del

cliente

Condición Inicial El usuario (cliente) debe estar registrado en el sistema y tener citas asignadas
Condición Final Cita reprogramada
Nota: En caso de no tener agenda disponible con el especialista el sistema notificara
al usuario mediante un mensaje “en este momento su especialista no cuenta
con agenda disponible, por favor intente más tarde”

Caso de uso 06. Registrar los servicios que ofrece el proveedor especialista y la
agenda que dispone.
Fuentes Product Owner que proporciono información de esta funcionalidad
Actor Usuarios (proveedor especialista)
Descripción Permite a los usuarios (proveedor especialista) Registrar los servicios que
ofrece y la agenda que dispone.
Flujo • El especialista registrado ingresa al sistema.
• El especialista selecciona la opción registrar servicio. Diligencia los detalles de
su servicio.
• A continuación le aparece la opción registrar disponibilidad de agenda
disponible. El usuario registra su agenda.
Condición Inicial El usuario especialista debe estar registrado en el sistema
Condición Final Servicio y agenda registrados

Caso de uso 07. Consultar las sesiones que tiene agendadas el proveedor
especialista.
Fuentes Product Owner que proporciono información de esta funcionalidad
Actor Usuarios (proveedor especialista)
Descripción Permite a los usuarios (proveedor especialista) Consultar las sesiones
que tiene agendadas
Flujo • El usuario (proveedor especialista) registrado ingresa al sistema
• El usuario (proveedor especialista) selecciona la opción ver ocupación de
agenda.
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

• El usuario (proveedor especialista) visualiza detalladamente las sesiones

programadas.
Condición Inicial El usuario (proveedor especialista) debe estar registrado en el sistema y
tener registrados servicios y agenda disponible
Condición Final Visualización detallada de las sesiones que tiene agendadadas.

Caso de uso 08. Consulta la información de los usuarios que han solicitado sus
servicios.
Fuentes Product Owner que proporciono información de esta funcionalidad
Actor Usuarios (profesional proveedor)
Descripción El aplicativo debe permitir al profesional revisarla información de los
usuarios que han solicitado sus servicios.
Flujo • El usuario (profesional proveedor) debe ingresar al aplicativo.
• El usuario (profesional proveedor) dispondrá de varias opciones.
• El usuario (profesional proveedor) accede a la opción de clientes.

Condición El usuario (profesional proveedor) debe estar registrado en el sistema y ver

Inicial toda la información del cliente.
Condición Final Listado de los usuarios que necesitan de sus servicios con orden de registro.

Caso de uso 09. Reporte de profesionales de la salud registrados.

Fuentes Product Owner que proporciono información de esta funcionalidad
Actor Usuarios (administrador)
Descripción Permite al administrador ver el reporte de los profesionales registrados.
Flujo • El usuario (administrador) debe ingresar en el aplicativo.
• El usuario (administrador) accede al módulo de reportes.
• El aplicativo despliega todos los reportes de cada usuario (profesional
proveedor) que estén creados.
Condición El usuario (administrador) debe estar registrado en el sistema y tener sus
Inicial respectivos permisos.
Condición Final Reporte de cada profesional, guardo con el usuario que lo creo.
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

Caso de uso 10. Reporte de usuarios registrados.

Fuentes Product Owner que proporciono información de esta funcionalidad
Actor Usuarios (administrador)
Descripción Permite consultar el reporte de todos los usuarios (clientes), registrados.
Flujo • El usuario (administrador) ingresa al sistema.
• El usuario (administrador) debe acceder a la pestaña (reporte de clientes).
• Se despliega todos los reportes creados desde los usuarios (clientes).
Condición Inicial El usuario (cliente) debe estar registrado en el sistema y puede observar sus
reportes creados con datos completos del cliente.
Condición Final Reporte de usuario (cliente).

Caso de uso 11. Agenda un profesional específico.

Fuentes Product Owner que proporciono información de esta funcionalidad
Actor Usuarios (cliente)
Descripción Permite a los usuarios (cliente), agendar una cita con el profesional que el desee.
Flujo • El usuario (cliente) registrado ingresa al sistema
• El usuario (cliente) debe elegir la opción agenda un profesional especifico.
• Allí se despliega un listado de todos los especialistas o profesionales, que estén
registrados en el sistema y puede buscar o filtrar por el nombre del que el cliente desee.
• Una vez a escogido al especialista o profesional, puede agendar con el que desee, día,
hora, y la disponibilidad que el mismo tenga en la semana.
Condición El usuario (cliente) debe estar registrado en el sistema y poder agendar una cita con
Inicial el profesional que ella guste.
Condición Final Queda registrado en el sistema la cita con el especialista o profesional que el cliente
eligió.

Caso de uso 12. Agenda de un usuario específico.

Fuentes Product Owner que proporciono información de esta funcionalidad
Actor Usuarios (profesional proveedor)
 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

Descripción Permite a los usuarios (profesional proveedor), tener acceso de agendar a

cualquier tipo de usuario, teniendo los permisos para poder acceder a la
base de datos de los usuarios (clientes).
Flujo • El usuario (profesional proveedor) registrado ingresa al sistema.
• El usuario (profesional proveedor) tendrá una pestaña de cliente especifico.
• Al seleccionar esta opción, le sale una lista de los clientes que seleccionan sus
servicios.

Condición Inicial El usuario (cliente) debe estar registrado en el sistema y tener permisos
para agendarle una nueva cita a ese usuario especifico.
Condición Final El usuario (cliente) deberá estar registrado en el sistema.

Caso de uso 13. Consultar cuáles son los servicios más solicitados.
Fuentes Product Owner que proporciono información de esta funcionalidad
Actor Usuarios (administrador)
Descripción El usuario (administrador) tiene permisos para saber qué servicios son los
más solicitados y con que profesionales.
Flujo • El usuario (administrador) registrado ingresa al sistema.
• El usuario (administrador)debe elegir la opción agenda reportes.
• Se abre una ventana donde le muestra al administrador las opciones de reporte
que tiene el software.
• El administrador selecciona la opción reporte de servicios, y el software carga
el opción y tiene opción de búsqueda.
• El administrador selecciona la opción correspondiente y espera que cargue el
reporte solicitado.
Condición Inicial El usuario (administrador) debe tener permisos en el sistema.

Condición Final Podrá ver qué servicios son los más solicitados.

2.3 Especificación adicional de los requerimientos no funcionales de su aplicación.

 Facultad de Ingeniería, Diseño e Innovación
Ingeniería de software 1

Trabajo colaborativo

2.4 Los diagramas de clases que corresponden al diseño detallado que satisface los requerimientos
identificados.

Referencias

• Escenario 3, 4 y 5 desarrollo de software, Politécnico Grancolombiano