ENTREGA PROYECTO 3 ESCENARIO 7 Consolidado Grupal Ingeniería de Software

PROYECTO INGENIERIA DE SOFTWARE 1
ENTREGA PROYECTO 3
ESCENARIO 7
PRESENTADO POR:
JHON ALEXANDER RAMIREZ BERMEO
SANTIAGO ANDRES HERNANDEZ BELTRAN
EDWARD MENDEZ GONZALEZ
LIZETH YUBELLY URREGO SANDOVAL
OSCAR JAVIER VARGAS DÍAZ
GRUPO B01
SUBGRUPO 2
PRESENTADO A: TUTORA
MAHECHA NIETO ISABEL ANDREA
POLITECNICO GRANCOLOMBIANO INSTITUCION UNIVERSITARIA

INGENIERÍA DE SOFTWARE
2021
Tabla de Contenido
INTRODUCCIÓN ................................................................................................................................... 6
OBJETIVOS ........................................................................................................................................... 7
Objetivos Principales....................................................................................................................... 7
Objetivos Generales ........................................................................................................................ 7
JUSTIFICACION................................................................................................................................ 8
MODELO DE PROCESO EN ESPIRAL VS OTROS MODELOS DE PROCESO ......................... 9
Porque rechazamos el Modelo de Proceso en V o en Cascada ....................................................... 9
Porque rechazamos el Modelo de Proceso en Prototipos .............................................................. 10
Porque rechazamos el Modelo de Proceso Incremental ................................................................ 10
Porque seleccionamos el Modelo de Proceso en espiral ............................................................... 11
RIESGOS ASOCIADOS Y MITIGACION DEL RIESGO EN EL MODELO DE PROCESO EN
ESPIRAL........................................................................................................................................... 12
Desventajas Modelo de Proceso espiral en desarrollo de software ............................................... 12
Riesgos asociados.......................................................................................................................... 12
Mitigación de los Riegos ............................................................................................................... 13
Paso 1: Definir Objetivos, alternativas condiciones generales: ........................................... 13
Paso 2: Evaluación de alternativas: ....................................................................................... 13
Paso 3: Desarrollo del Producto real y revisión del resultado intermedio: ........................ 13
Paso 4: Planificación del siguiente ciclo: ............................................................................... 13
ACTIVIDADES A REALIZAR PARA LA EJECUCION DEL PROYECTO ................................ 14
........................................................................................................................................................... 14
Análisis de requerimientos ............................................................................................................ 14
OBSERVACIÓN .......................................................................................................................... 15
ENTREVISTAS ............................................................................................................................ 15
Diseño ........................................................................................................................................ 16
Codificación o desarrollo ........................................................................................................... 16
Implementación ........................................................................................................................ 17
Evaluación ................................................................................................................................. 17
MODELOS VISUALES Y PROTOTIPOS .................................................................................. 17
SESIONES JAD ............................................................................................................................ 17
ROLES .............................................................................................................................................. 18
Director del Proyecto .................................................................................................................... 18
Líder de Proyecto .......................................................................................................................... 18
Desarrollador ................................................................................................................................. 18
Tester ............................................................................................................................................. 18
CRONOGRAMA DE ACTIVIDADES ............................................................................................ 19
........................................................................................................................................................... 20
REQUERIMIENTOS DEL SOFTWARE......................................................................................... 21
Requerimientos Funcionales ......................................................................................................... 21
Rol de Cliente: ......................................................................................................................... 21
Rol de Profesional: .................................................................................................................. 22
Rol de Administrador del Sistema: ........................................................................................ 22
REQUERIMIENTOS NO FUNCIONALES ................................................................................ 22
ESPECIFICACION DE LOS REQUERIMIENTOS FUNCIONALES MEDIANTE CASOS DE
USO ................................................................................................................................................... 24
DIAGRAMAS DEL SISTEMA .................................................................................................... 24
Diagrama de casos de uso: ........................................................................................................ 24
Diagrama de Clases: .................................................................................................................. 25
....................................................................................................................................................... 25
DESCRIPCIÓN DE LOS ACTORES........................................................................................... 26
Actor No: 1 ................................................................................................................................ 26
Actor No: 2 ................................................................................................................................ 27
Actor No: 3 ................................................................................................................................ 27
ESPESIFICACION DE CASOS DE USO .................................................................................... 28
REGISTRO................................................................................................................................... 28
INICIO DE SESION ...................................................................................................................... 29
REGISTRAR SERVICIOS MEDICOS ............................................................................................... 30
CONSULTAR AGENDA PROGRAMADA ....................................................................................... 31
CONSULTAR INFORMACION DETALLADA DE PERSONAS QUE AGENDARON ............................ 31
BUSCAR PROFESIONAL .............................................................................................................. 32
SELECCIONAR PROFESIONAL ..................................................................................................... 33
RESERVAR SESION ..................................................................................................................... 34
PAGAR EN LINEA........................................................................................................................ 35
MODIFICAR AGENDA ................................................................................................................. 36
REPORTE PROFESIONALES REGISTRADOS ................................................................................. 37
REPORTE USUARIOS CLIENTE PREPAGADO REGISTRADOS ....................................................... 38
DETALLE AGENDA PROFESIONAL ESPECIFICO ........................................................................... 39
DETALLE AGENDA USUARIO ESPECIFICO .................................................................................. 39
CONSULTAR SERVICIOS MAS SOLICITADOS .............................................................................. 40
DIAGRAMAS DE SECUENCIAS ............................................................................................................ 42
Diagrama de Secuencias Funcionalidades Actor Usuario Cliente Prepagado .............................. 42
................................................................................................................................................... 42
Diagrama de Secuencias Funcionalidades Actor Usuario Profesional Medico ............................ 44
....................................................................................................................................................... 44
Diagrama de Secuencias Funcionalidades Actor Administrador del Sistema ............................... 45
....................................................................................................................................................... 45
DIAGRAMAS DE ESTADOS ................................................................................................................. 46
Login ............................................................................................................................................. 46
........................................................................................................................................................... 46
Registro ......................................................................................................................................... 47
........................................................................................................................................................... 47
Usuario Cliente Prepagado ............................................................................................................ 48
........................................................................................................................................................... 48
Usuario Profesional Medico .......................................................................................................... 49
........................................................................................................................................................... 49
SUSTENTACION ................................................................................................................................. 50
La sustentación del proyecto se realizará mediante un video donde se expondrán algunas partes
fundamentales del Proyecto. Para ello hemos grabado un video y lo hemos subido a la plataforma
de YouTube........................................................................................................................................ 50
Enlace video Sustentación https://youtu.be/4e4nMzfPRDw ........................................................... 50
REFERENCIAS ................................................................................................................................ 51
Tabla de Ilustraciones
Ilustración 1. Análisis de Requerimientos. Clico de vida del Software ............................................. 14
Ilustración 2. Cronograma de Actividades. Elaboración Propia ........................................................ 20
Ilustración 3. Diagrama de Casos de Uso. Elaboración Propia .......................................................... 24
Ilustración 4Diagrama de clases. Elaboración Propia ....................................................................... 25
Ilustración 5. Diagrama de Secuencias UCP parte 1. Elaboración Propia. ........................................ 42
Ilustración 6. Diagrama de Secuencias UCP parte 2. Elaboración Propia. ........................................ 43
Ilustración 7. Diagrama de Secuencias Funcionalidades Actor UPM. Elaboración Propia. ............... 44
Ilustración 8. Diagrama de Secuencias Funcionalidades Actor Administrador del Sistema.
Elaboración Propia. ........................................................................................................................... 45
Ilustración 9. Diagrama de Estados -Log in ....................................................................................... 46
Ilustración 10. Diagrama de Estados -Registro ................................................................................. 47
Ilustración 11. Diagrama de Estados -UCP ........................................................................................ 48
Ilustración 12. Diagrama de Estados -UPM ....................................................................................... 49
INTRODUCCIÓN
Como es bien sabido la industria del software ha venido representando una gran importancia
en el mundo actual, ofreciéndonos nuevas oportunidades laborales y puertas abiertas a nuevas
oportunidades de negocio. Gracias al continuo avance tecnológico que se ha venido
presentando, la industria del software ha crecido de manera exponencial, no solo
manifestándose y consolidándose como una de las principales actividades económicas
actuales, sino muestra de ello el desarrollo de software ha permeado en todos los ámbitos de
la vida cotidiana y cumple hoy en día una pieza fundamental del día a día.
Uno de los aspectos más importantes a los que nos a llevado la industria del software es a
que en la actualidad son muchas las organizaciones que definen métodos y técnicas para que
el desarrollo de software sea cada día de mucha más alta calidad. El proceso de software
puede ser definido como un; quién, qué, cuándo, y cómo alcanzar un determinado objetivo.
El objetivo de la ingeniería de software es construir un producto de software o mejorar alguno
ya existente. Un proceso efectivo de software es aquel que brinda normas para una correcta
construcción de un software de calidad, determinando un proceso que debería ser capaz de
mejorar a través de los años.
En esta oportunidad se presentará un análisis de la primera fase del Desarrollo del software
donde analizaremos los roles, cronograma, artefactos, requerimientos, actores y demás
elementos que son necesarios para el desarrollo de este.
OBJETIVOS
Objetivos Principales
Dar a conocer de manera argumentativa el Modelo de Proceso seleccionado que satisfará

las necesidades argumentadas por el cliente.
Identificación de requerimientos que satisfarán las necesidades de nuestro cliente.
Representar Mediante Diagramas de Secuencias y estados el comportamiento del sistema.
Objetivos Generales
Justificar la elección realizada del Modelo de Proceso con respecto al proyecto actual que
satisfará las necesidades argumentadas por el cliente.
Comparar el Modelo de Proceso seleccionado con los demás Métodos de Proceso
existentes.
Definir cuáles son los riesgos asociados a Modelo que hemos seleccionado y compararlo
con otros Modelo de Proceso existentes.
Proponer acciones de mitigación para los riesgos existentes asociados a Modelo que hemos
seleccionado.
Diferenciar los requerimientos funcionales y no funcionales.
Especificar todos los requerimientos funcionales a través de casos de usos detallados.
Identificar los requerimientos no funcionales.
Representar mediante diagramas la estructura de las funcionalidades.
JUSTIFICACION
Con el fin de tener la certeza y de tomar una decisión correcta a la hora de elegir un Modelo
de Proceso para el Desarrollo del Software, son muchas las variables que entran en juego y
de las cuales tenemos que verificar cuales son aquellas que nos brindan más afinidad, en
cuanto a satisfacer las necesidades planteadas por el cliente.
Existen muchas variables que debemos tomar en cuenta para poder seleccionar el Modelo de
Proceso de Software, entre ellas los costos de producción, las expectativas en cuanto al
tiempo de desarrollo por parte del cliente, las probabilidades de éxito, las herramientas
adecuadas, el equipo de desarrollo correcto, etc.
Para poder considerar estas variables, es necesario comparar con los diferentes Modelos de
Proceso y tomar decisiones que favorezcan en común acuerdo, en cuanto a satisfacer las
expectativas del cliente y en tanto a consolidar o llevar a cabo de manera correcta el desarrollo
del Software.
Teniendo claro que nuestro cliente manifiesta de una manera poco segura o de poca
asertividad, cuáles son sus necesidades, es necesario que el Método de Proceso de Software
a implementar nos brinde la oportunidad de evaluar constantemente la satisfacción de las
necesidades del cliente mediante un producto que se actualice en el tiempo, es decir la
utilización de prototipos o versiones que implementen todas las funcionalidades y los
requerimientos inicialmente solicitados por el cliente, dándonos la oportunidad de corregir y
mitigar errores ocurridos tanto en la lógica del Software como en su interfaz de usuario.
Es así como seleccionamos el Modelo de Proceso en espiral, fijándonos inicialmente que
nuestro cliente cree conocer cuáles son sus necesidades, pero aun así no demuestra seguridad.
Creemos que, si nuestro cliente cree tener la “certeza” no segura, de cuáles son sus
necesidades. Esto instantáneamente nos demuestra que un Modelo en Cascada donde exista
un único producto final, no sería la manera correcta de garantizar la completa satisfacción
del cliente. A su vez el Modelo de Prototipos podría funcionar siempre y cuando tuviéramos
la certeza de que el cliente no requerirá algún cambio en el software que demande nuevas
iteraciones y que la representación de un prototipo no funcional incremente o genere mayor
inseguridad con respecto a tiempos y el desarrollo de nuevas funcionalidades no previstas o
requeridas anteriormente.
En cambio, creemos que, al presentar un prototipo funcional con los requerimientos
primeramente solicitados, los usuarios podrán dirigir su retroalimentación de manera más
eficaz, esto seguido nos llevara a la construcción de un software que supla todas las
necesidades planteadas. Además, creemos que quizás necesitando solo una segunda o tercera
versión podría ser suficiente para satisfacer las necesidades del cliente y así finalizar el ciclo
de vida del software.
A continuación, adentraremos en una demostración más detallada realizando una
comparación entre los diferentes Modelos de proceso con la finalidad de justificar de una
manera mucho más detallada por qué hemos seleccionado el Modelo de Proceso en espiral
como el Modelo de Proceso que satisface las necesidades del presente proyecto de desarrollo
de software.
MODELO DE PROCESO EN ESPIRAL VS OTROS MODELOS DE PROCESO
El propósito de esta sección es demostrar de una manera comparativa por que decidimos
seleccionar el Modelo de Proceso en espiral y no otro tipo de Modelo de Proceso. Para ello
nos basamos en sus características, así como ventajas y desventajas.
Primeramente, es necesario conocer cuál es la historia de usuario. De esta manera podemos
obtener una idea de lo que el usuario desea realmente. Puesto a que el cliente o usuario (cree
conocer sus necesidades), es decir no está seguro realmente.
Nosotros nos basamos desde este punto de vista: que nuestro cliente no tiene certeza de lo
que realmente espera obtener y puede ser muy posible que no esté conforme con el producto
final.
Porque rechazamos el Modelo de Proceso en V o en Cascada
• Primeramente, porque en este Modelo de Proceso se depende de requisitos estable y

correctos, por lo cual creemos que el cliente cree tener seguridad de sus necesidades,
pero no creemos notablemente que sea así.
• Retrasa la detección de errores hasta el final del proceso, siendo así podríamos
entregar un software que no satisfaga las necesidades del cliente y que la mayoría de
los errores sean avistados por los usuarios.
• No se promueve la reutilización del software y no se promueve el uso de prototipos,

siendo así el cliente recibirá una única versión del software y no tendríamos ocasión
a modificaciones o actualizaciones.
• Toma demasiado tiempo en ver resultados. Al ser así creemos que las expectativas y
la ansiedad del cliente aumentaran cada vez más al no poder ver resultados prontos,
o por lo menos tener una visual de un prototipo del software. Esto nos llevaría a que
el cliente no reciba un producto que satisfaga sus expectativas.
Porque rechazamos el Modelo de Proceso en Prototipos
• Creemos que cualquier aplicación que presenta mucha interacción con el usuario, o
que requiera de algoritmos que deban ser construidos de manera evolutiva, de menos
a cada vez más, es un excelente candidatos a utilizar este Modelo de Construcción o
Proceso por Prototipos. Sin embargo, hay que tener en cuenta que aplicar mucha
lógica y demasiado esfuerzo en cuanto a código y tiempo para entregar al cliente un
prototipo no funcional, sabiendo de antemano que el cliente presenta algunos
requerimientos que son fundamentales pero que a su vez no sabemos con certeza
cuales pueda cambiar, porque no demuestra plena seguridad en cuanto a sus
necesidades.
• Creemos que utilizar este Modelo por Prototipos nos puede llevar en la vida real a
perdidas de dinero, tiempo y equipo de trabajo. Si bien el prototipo servirá para
modelar o mostrar al cliente como se realizará la entrada y salida de los datos , de
modo que pueda hacerse a una idea de cómo se presentara el sistema al final del
proceso de desarrollo, con esto se podrían mitigar ciertos errores, pero sabemos que
el modelo no es más que algo no funcional y que no representa un objeto que nos
indique una plena retroalimentación de si estamos haciendo o no lo correcto en el
proceso de desarrollo.
Porque rechazamos el Modelo de Proceso Incremental
Aunque es una muy buena idea el poder obtener un desarrollo totalmente funcional entre 60
y 90 días, y que permite una gran reutilización (Repositorios) para posteriores proyectos, las
razones por las que no elegimos este Modelo de Proceso son las siguientes:
• Tener varios equipos de Desarrollo en paralelo puede implicar recursos económicos
bastante importantes que deben tenerse en cuenta.
• Deben existir Desarrolladores muy experimentados quienes entiendan a cabalidad las

necesidades del cliente y puedan dar solución a estas mismas.
• Debe existir un compromiso por parte del cliente y el equipo de Desarrollo para llevar
a cabo el desarrollo rápido de las actividades.
Porque seleccionamos el Modelo de Proceso en espiral
• Este Modelo se basa en una estrategia de reducción del riesgo, caso contrario al
modelo en cascada o en V que son dirigidos por documentos.
• Se realiza una rigurosa evaluación del riesgo antes de proceder al siguiente ciclo.
• No es necesario la definición completa de los requisitos para comenzar una iteración.
• El cliente se sentirá más satisfecho trabajado de la mano del equipo de desarrollo y

recibiendo prototipos funcionales por cada iteración.
• Cada ciclo del modelo de espiral termina con una revisión donde se discuten los
logros actuales y los planes para el siguiente ciclo, con el propósito de lograr la
incorporación de todos los miembros del grupo para su continuación.
• La revisión cíclica puede determinar si desarrollos posteriores van o no a satisfacer

las metas definidas y los objetivos del proyecto. En tal caso, se terminaría el espiral.
• Los recursos económicos se plantean en cada ciclo, determinado si es viable o no

generar una nueva iteración.
RIESGOS ASOCIADOS Y MITIGACION DEL RIESGO EN EL MODELO DE
PROCESO EN ESPIRAL
El Modelo de Proceso en espiral a diferencia del modelo en cascada no parte de la base común
de tareas que desarrollan de manera lineal, sino que estas se entienden como tareas iterativas.
Las fases no se cumplen de una manera lineal y única sino en vez de esto las tareas se
desarrollan varias veces en forma de espiral. Se trata de repeticiones cíclicas donde el
proyecto de desarrollo se va acercando cada vez más a la meta pactada, pero de una forma
un poco lenta. Razón por la cual se logra mitigar en gran manera el riesgo a fracasar en el
desarrollo y esto a su vez gracias al sistema de controles regulares.
Desventajas Modelo de Proceso espiral en desarrollo de software
● Agotamiento en procesos que se tornan repetitivos para alcanzar las mejoras en el

producto, esto por la comunicación permanente con el cliente.
● En equipos de desarrollo muy grandes con poca experiencia se puede presentar algo
de complejidad al utilizar este método, pues se pueden desdibujar los roles y no
distribuir equitativamente tareas.
● Este método necesita de experiencia, personas con conocimientos sólidos para un
rendimiento óptimo en equipo, pues el retraso de alguno desencadenará en costos e
incumplimiento de entrega de producto.
● El tiempo es un factor determinante, cualquier pausa en el proceso no planeada podría
afectar la entrega óptima y oportuna del producto.
Riesgos asociados
• Mala gestión del grupo de trabajo

• Debe existir una sinergia en el equipo de trabajo, donde se le haga acompañamiento
y seguimiento a labores asignadas.
• Adaptación al modelo por parte del equipo de trabajo
• El compromiso por parte de cada integrante será determinante para el desarrollo que
se quiere del método.
• Se pierde tiempo al volver a producir una especificación completa de los
requerimientos cuando se modifica o mejora el software.
• Es difícil convencer a clientes de que este método con un enfoque evolutivo es
controlable.
Mitigación de los Riegos
Para culminar un ciclo de desarrollo en espiral se tienen 4 pasos fundamentales y es aquí

donde podemos demostrar la manera como se mitigarán los riesgos no solo para este
proyecto sino para cualquier proyecto basado en el Modelo de Proceso en espiral.
Paso 1: Definir Objetivos, alternativas condiciones generales:
Se definen cuales son los objetivos que deben cumplirse paso a paso en el desarrollo del
proyecto. En este caso definimos como objetivos al desarrollo de cada una de las
funcionalidades de la aplicación requerida por nuestro cliente. Además, definimos tanto
temas ligados al presupuesto, costos, tiempos y equipo de trabajo.
Paso 2: Evaluación de alternativas:
Es aquí donde se evalúan los ámbitos de seguridad e inseguridad ligados a riegos que
puedan incidir sobre el proceso de desarrollo. En el caso de nuestro cliente podemos utilizar
estrategias rentables como realizar encuestas, probar simulaciones y prototipos donde con
la ayuda de los usuarios o profesionales que ofrecerán los servicios, se pueda tener cierta
retroalimentación en cuanto a lo que va a satisfacer sus necesidades.
Paso 3: Desarrollo del Producto real y revisión del resultado intermedio:
En esta fase se verifican los riegos relativos restantes, es decir son aquellos riegos ligados al
desarrollo real del software. Por decir un ejemplo los riegos ligados al código, al diseño de
interfaz de usuario, riegos ligados a la seguridad y operatividad del sistema. Estos riegos
son mitigados mediante el uso de pruebas unitarias de código, además de retroalimentación
por parte del usuario final para la capa de vista o IU. Se busca optimizar los prototipos y
tener un código reutilizable.
Paso 4: Planificación del siguiente ciclo:
Como bien sabemos, al finalizar un ciclo se inicia la planificación del siguiente. Se analiza
el resultado obtenido con respecto a los objetivos que se habían propuesto, en caso de haber
cumplido se procede a la planificación de los siguientes objetivos. Si algunos de los
objetivos propuestos no se cumplieron se buscará la manera de dar solución a estos
objetivos mediante el uso de otras alternativas.
ACTIVIDADES A REALIZAR PARA LA EJECUCION DEL PROYECTO
Ilustración 1. Análisis de Requerimientos. Clico de vida del Software
Análisis de requerimientos
A partir de la descripción que haga el cliente sobre lo que quiere, se abstrae toda la
información necesaria y útil para el desarrollo del producto solicitado de una manera
“jerárquica”, donde se puede establecer la necesidad tecnológica, características
operacionales y comportamiento del software, también se priorizan los requerimientos y se
elimina todo lo que genere ambigüedades.
Una de las actividades que realizaremos para ejecutar el proyecto es utilizar los métodos y
técnicas de recolección de datos, con el fin de reunir y medir información de diversas
fuentes obteniendo así un panorama completo y preciso sobre el proyecto a desarrollar
permitiendo tener más claro el enfoque y evaluar así las necesidades de los clientes
anticipando las probabilidades de solución y decisiones necesarias para el cumplimiento de
este.
Entre las técnicas de recolección de información utilizaremos las más conocida las cuales
son:
OBSERVACIÓN
Se realiza un registro visual de lo que ocurre en la situación real, en este caso analizamos
la situación planeada por la actividad la cual es “Se necesita una herramienta que me
permita registrar una serie de profesionales de la salud que ofrecen diferentes servicios de
acuerdo con una agenda definida y permitir a los usuarios en línea buscar el profesional que
más se adapta a sus necesidades y agendar una cita con esta profesional una vez ha
realizado el respectivo pago del servicio”
ENTREVISTAS
Es una técnica de recopilación de información mediante contacto directo con las personas,
a través de una conversación interpersonal, preparada bajo una dinámica de preguntas y
respuestas, donde se dialoga sobre un tópico relacionado con la problemática de
investigación.
En este caso utilizaremos el tipo de entrevista estructurada en el cual manejaremos un
cuestionario previamente preparado de preguntas abiertas y cerradas elaborado de forma
secuencial y dirigido, buscando así respuestas concretas que nos confirme lo requerido por
el cliente.
Las preguntas se desarrollarán de la siguiente manera:
• ¿Qué problema se está tratando de solucionar? R=.
• ¿Cuál sería una solución exitosa para usted y por qué? R=
• ¿Cuál es la motivación para resolver este problema? R=
• ¿Quién podría influir en el proyecto? R=
• ¿Podría haber consecuencias no deseadas con el desarrollo del producto? R=
• ¿Existen algunas políticas que se deban contemplar para el producto? R=
• ¿Qué palabras usaría para describir el producto que se requiere? R=
• ¿Qué aspectos considera son los más y menos valiosos para los usuarios? R=
• ¿Qué cualidades considera las más críticas para las distintas funcionalidades del
sistema, ejemplo, consultar Profesionales, consultar Usuarios? R=
• Solicitarle los formatos que actualmente usa para cumplir con lo que se va a
automatizar
• ¿Hay algo más que deba preguntarle? R=
Diseño
Todas las actividades que intervienen en el desarrollo de un producto de software son

importantes, en esta en particular, permite producir varios modelos tentativos del producto
o sistema que se desea construir, evaluando calidad y posibles mejoras antes de generar
código.
Se realizarán prototipos y muestras con el fin de dar vida a cualquier diseño que nos pueda
proporcionar una gran cantidad de información sobre la interacción del usuario, esto nos
permite poner a prueba la viabilidad y la utilidad del diseño antes de iniciar con el desarrollo
o paso a otra etapa de nuestro proyecto. SESIONES JAD Se llevará a cabo programación de
sesiones JAD en las cuales se interactúe con el cliente y se garantice el trabajo en equipo
entre el cliente, el usuario y nosotros como proveedor, dando así una participación más activa
del cliente con el ciclo de vida del método elegido, permitiendo así identificar las necesidades
planteadas, corroborar los requerimientos, mostrar los prototipo y avances con el fin de que
todo quede claro y dar la más oportuna solución a lo solicitado
- Acercamiento a una construcción de base de datos.

- Identificación de entidades y atributos.
- Construcción de un modelo entidad relación
- Posible implementación de gestor de base de datos
- Diseño de ventanas e interfaces.
- Interacción de usuarios
Codificación o desarrollo
Una vez finalizada la etapa o la actividad de diseño, se puede iniciar la codificación, donde
se van a traducir algoritmos a un lenguaje de programación, teniendo en cuenta todos los
requerimientos funcionales y es tal vez la actividad que más lleva tiempo, o es la más
representativa.
- Código fuente
- Código objeto
- Código ejecutable
Implementación
En esta actividad, se verifica que todos los requerimientos o especificaciones se cumplan a

cabalidad, encontrando posibles errores para mejoras en diseño y codificación.
- Puesta en marcha del producto en versión beta

- Pruebas en interfaz de los diferentes usuarios
- Verificación de tiempos en ejecución de instrucciones
Evaluación
Con el producto en marcha, durante esta actividad se enfrentan errores recién descubiertos y
alcances a los requerimientos propuestos en primera instancia.
- Capacitación y acompañamiento a usuarios mientras se establece el producto.

- Transición si existe un producto anteriormente.
- Corrección de errores (bugs)
MODELOS VISUALES Y PROTOTIPOS

Se realizarán prototipos y muestras con el fin de dar vida a cualquier diseño que nos pueda
proporcionar una gran cantidad de información sobre la interacción del usuario, esto nos
permite poner a prueba la viabilidad y la utilidad del diseño antes de iniciar con el
desarrollo o paso a otra etapa de nuestro proyecto.
SESIONES JAD
Se llevará a cabo programación de sesiones JAD en las cuales se interactúe con el cliente y
se garantice el trabajo en equipo entre el cliente, el usuario y nosotros como proveedor,
dando así una participación más activa del cliente con el ciclo de vida del método elegido,
permitiendo así identificar las necesidades planteadas, corroborar los requerimientos,
mostrar los prototipo y avances con el fin de que todo quede claro y dar la más oportuna
solución a lo solicitado
ROLES
Director del Proyecto

Es la persona encargada de tener contacto con el cliente para tomar decisiones respecto a
las funcionalidades del sistema, cambios y otro tipo de requerimientos no funcionales.
Aportará para el diseño del cronograma de actividades base.
Contribuirá con de levantamiento de requerimientos y su análisis.
Además, tendrá contacto directo y retro alimentación con el Líder del Proyecto y revisando que
todos los procesos en el equipo se estén llevando a cabo o sino investigar falencias y planear el
proceso cambiado para la siguiente iteración o si no hay tiempo en la misma.
Líder de Proyecto
Orientar y liderar el trabajo del equipo en cuanto a reuniones semanales, objetivos, errores
en el proceso. Estará encargado de aprobar y verificar procesos base principalmente y de
asegurarse que los partícipes del proyecto se sientan bien seguros tanto en la construcción como en
el análisis de los riesgos. Se encargará de liderar el ciclo de Desarrollo.
Desarrollador
Es el rol que le damos a cada persona que interactúa con el código, Cada desarrollador
tendrá objetivos semanales, se tendrán diferentes medios de comprobación del código,
mediante repositorios en GitHub, además usara herramientas tradicionales para la
validación de los objetivos de codificación.
Este dispondrá y definirá las herramientas base para poder empezar la codificación del proyecto. El
definirá prototipos, demos o versiones Alpha para mostrar y dar contenido visual al equipo que
permita hacerse la idea de lo que se planea construir y disminuir el riesgo que conlleva a veces no
tener una demostración real de lo que se necesita desarrollar.
Tester
Este rol se encargará de realizar las pruebas unitarias del sistema, hace parte del equipo de
desarrollo, pero su rol fundamental será Testear el código y generar reportes al Líder de
Proyecto con el fin de que cada Desarrollador genere commits que puedan ser evaluados
para posteriormente corregirlos y tener la unificación de un código funcional t con buenas
prácticas. Además de esto el Tester tendrá que elaborar los datos a procesar, lanzar los
programas creados, verificar los resultados diseñará la base de datos, pondrá en producción
la aplicación.
En un equipo de trabajo del método de espiral se define la localización de sus aplicaciones,
datos de ejecución y documentos de resultados.
El siguiente cuadro Resume los Roles de las personas que interactuaran en el Proyecto:
Directo de Líder de Desarrollador Desarrollador Tester

Proyecto Proyecto
Jhon Ramírez Edward Méndez Oscar Vargas Lizeth Urrego Santiago
CRONOGRAMA DE ACTIVIDADES
La siguiente imagen representa el cronograma de actividades propuesto:

Ilustración 2. Cronograma de Actividades. Elaboración Propia
REQUERIMIENTOS DEL SOFTWARE
Requerimientos Funcionales
Los requerimientos funcionales hacen referencia a los servicios que proveerá el sistema, de
la manera en que este reaccionará a entradas particulares. En algunos casos, los
requerimientos funcionales de los sistemas también indican claramente lo que el sistema no
debe hacer. La gran mayoría de los problemas de la ingeniería de software provienen de la
imprecisión en las especificaciones de requerimientos; para un ingeniero es natural dar
conceptos o interpretaciones de un requerimiento ambiguo con el fin de facilitar su
desarrollo. Sin embargo, no es lo que el cliente desea. Se tienen que estipular nuevos
requerimientos y se deben hacer cambios al sistema, retrasando la entrega del software e
incrementando costos.
En principio la especificación de requerimientos funcionales de un sistema debe estar

completa y ser concisa, completa significa que todos los servicios y requerimientos
solicitados por el cliente están definidos, y la consistencia significa que los requerimientos
no tienen definiciones contradictorias.
Rol de Cliente:
• 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.
Rol de Profesional:
• 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.
Rol de Administrador del Sistema:
• Generar reporte de profesionales de la salud registrados.

• Generar reporte de usuarios registrados.
• Generar reporte un profesional específico.
• Generar reporte de un usuario específico.
• Consultar cuáles son los servicios más solicitados.
REQUERIMIENTOS NO FUNCIONALES
Para los requerimientos no funcionales son aquellos que no se refieren directamente a las
funciones específicas que entrega el sistema, si no a las propiedades generales de este,
como la respuesta en tiempo, la capacidad de almacenamiento y rendimiento del sistema.
Surgen de la necesidad del usuario y definen como debe ser el sistema, se les suele llamar
como cualidades del sistema. En la práctica la especificación cuantitativa de requerimientos
es compleja, a los clientes les resulta difícil traducir sus objetivos en requerimientos
cuantitativos como para los de mantenimiento que no existen muchas métricas que se
puedan usar, el costo de verificar objetivamente los requerimientos no funcionales
cuantitativos es muy alto.
La distinción entre requerimientos funcionales y no funcionales no siempre resulta tan
palpable a simple vista, por ejemplo: la seguridad puede establecerse inicialmente como un
requerimiento no funcional, pero su elaboración puede inducir a nuevos requerimientos
funcionales como la necesidad de realizar una autenticación a los usuarios en el sistema.
Independientemente de si decidimos incluir este tipo de requisitos en un grupo u otro, lo en
realidad importante es identificarlos correctamente:
a. El sistema debe contar con internet para poder realizar todas las acciones deseadas.
b. El sistema debe ser capaz de realizar N transacciones por segundo.
c. El sistema debe tener una interfaz gráfica para su correcta manipulación.
d. El sistema debe contar con una Base de Datos Autónoma de Oracle Cloud
e. El sistema debe contar con tecnologías actuales en lenguaje de programación.
ESPECIFICACION DE LOS REQUERIMIENTOS FUNCIONALES MEDIANTE
CASOS DE USO
DIAGRAMAS DEL SISTEMA
Diagrama de casos de uso:
Ilustración 3. Diagrama de Casos de Uso. Elaboración Propia

Diagrama de Clases:
Ilustración 4Diagrama de clases. Elaboración Propia

DESCRIPCIÓN DE LOS ACTORES
Junta inicial.
“Necesito contar con una herramienta que me permita registrar una serie de profesionales
de la salud que ofrecen diferentes servicios de acuerdo con una agenda definida y permitir a
los usuarios en línea buscar el profesional que más se adapta a sus necesidades y agendar
una cita con esta profesional una vez ha realizado el respectivo pago del servicio”.
En la junta inicial con el Cliente pudimos identificar según sus necesidades, quienes serían
los Actores que interactuarían con el sistema. A continuación, se muestran a detalle:
Actor No: 1
Actor Profesional Identificador:

[UPM]
Descripción Usuario Profesional Medico (UPM). Persona
que proveerá servicios de Atención.
Características Crear y agendamiento servicios Médicos.
Relación El UPM Estable los servicios que serán
contratados por el Actor (UCP) Usuario
Cliente Prepagado
Referencias El UPM puede:
. Registrase e iniciar Sesión [UC-LOG-01]
[UC-LOG-02]
. Registrar Servicios [UC-UPM-01]
. Consultar Agenda Programada [UC-UPM-
02]
. Consultar Información Detallada de Usuarios
que Agendaron Cita [UC-UPM-03]
Nombre Nombre del UPM

Usuario Letras y números, mínimo 6 caracteres máximo 10
Contraseña Combinación de letras números y símbolos, mínimo 8
caracteres, máximo 14 caracteres.
Cedula Cedula del UPM
Dirección Dirección del UPM
Servicio Servicio Médico que se Ofrecerá
Fecha y Hora Servicio Fecha y hora del servicio a prestar
Duración Servicio Tiempo de duración del servicio
Multiusuario Atención a varios clientes al mismo tiempo
Costo Servicio Valor del Servicio
Tipo de Persona Jurídica o natural
Actor No: 2
Actor Cliente Identificador:
[UCP]
Descripción Usuario Cliente Prepagado (UCP). Persona que adquirirá y
consumirá los Servicios Médicos Programados por el UPM
Características Adquirir Servicios Médicos mediante agendamiento y pago de este.
Relación El UCP adquiere y consume los servicios del UMP, según agenda
disponible.
Referencias El UCP puede:
. Registrarse e Iniciar Sesión. [UC-LOG-01] [UC-LOG-02]
. Buscar Profesional: [UC-UCP-01]
. Seleccionar Profesional: [UC-UCP-02]
. Reservar Sesión: [UC-UCP-03]
. Pagar en Línea: [UC-UCP-04]
. Modificar Agenda: [UC-UCP-05]
Nombre Nombre del UCP

Usuario Letras y números, mínimo 6 caracteres máximo 10
Contraseña Combinación de letras números y símbolos, mínimo 8 caracteres,
máximo 14 caracteres.
Genero Masculino/Femenino/otro
Edad Mínimo mayor de 18 años
dirección dirección de residencia
Email Cuenta email personal o corporativo
Actor No: 3
Actor Administrador del Sistema Identificador:

[SAC]
Descripción Cliente Administrador del Sistema
Características Visualizar las actividades de Agenda, Cronograma, duración de los
servicios, cantidad de servicios, y detalle de UPM y UCP.
Relación Administrar (Lectura) de los servicios ofrecidos por los UPM y
Administrar (Lectura) de los servicios adquiridos por los UCP
Referencias El SAC puede:
. Reporte Profesionales Registrados [UC-SAC-01]
. Reporte Usuarios Cliente Prepagado Registrados [UC-SAC-02]
. Detalle Agenda Profesional Especifico [UC-SAC-03]
. Detalle Agenda Usuario Especifico [UC-SAC-04]
. Consultar Detalle Servicios [UC-SAC-05]
Nombre Nombre del SAC

Usuario ADMIN
Contraseña Combinación de letras números y símbolos, mínimo 8 caracteres,
máximo 14 caracteres. (Provista por Desarrollo)
Email Cuenta email personal o corporativo
ESPESIFICACION DE CASOS DE USO
REGISTRO
Caso de Uso REGISTRO EN EL SISTEMA Identificador:

[UC-LOG-01]
Actores UPM, UCP
Referencias N/A
Precondición El Profesional (UPM) no tiene aún creado su cuenta de inicio de
sesión.
El Usuario Cliente Prepagado (UCP) no tiene aún creada su cuenta de
inicio de sesión.
Postcondición El Profesional (UPM) ahora tiene una cuenta de inicio de sesión activa
en el sistema.
El Usuario Cliente Prepagado (UCP) ahora tiene una cuenta de inicio
de sesión activa en el sistema.
Descripción El Actor al no contar con una cuenta activa en el sistema, realizara el
registro pertinente, ingresando los datos solicitados por el mismo.
Curso Normal
Nro. Ejecutor Paso o Actividad

1 UPM, UCP Este caso de uso inicia cuando el Actor va a crear su perfil
2 SISTEMA El sistema comunica un conjunto de datos
3 UPM, UCP El Actor completa los datos.
4 SISTEMA El sistema verifica los datos ingresados con los requisitos
mínimos
5 SISTEMA El Sistema comunica que los datos son validos
6 SISTEMA El sistema envía correo de verificación a la bandeja de entrada
del correo electrónico ingresado por el Actor
7 UPM, UCP El Actor realiza la verificación del correo electrónico
8 SISTEMA El Sistema comunica que la verificación fue exitosa
9 Fin del caso de uso
Cursos Alternos
Nro. Descripción de acciones alternas

5.b El Sistema comunica que los datos NO son validos
6.B El Actor corrige los datos ingresados con los requisitos mínimos
7.B El Sistema comunica que los datos son validos
8.B El sistema envía correo de verificación a la bandeja de entrada del correo
electrónico ingresado por el Actor
9.B El Actor realiza la verificación del correo electrónico
10.B El Sistema comunica que la verificación fue exitosa
11B Fin del Caso de Uso
INICIO DE SESION
Caso de Uso LOG IN Identificador:

[UC-LOG-02]
Actores UPM, UCP
Referencias N/A
Precondición El Profesional (UPM) tiene creada su cuenta para iniciar sesión.
El Usuario Cliente Prepagado (UCP) tiene creada su cuenta para
iniciar sesión.
Postcondición El Profesional (UPM) ha iniciado sesión.
El Usuario Cliente Prepagado (UCP) ha iniciado sesión.
Descripción El Actor cuenta con una cuenta registrada para realizar el inicio de
sesión, al utilizar su usuario y contraseña anteriormente creados, podrá
ingresar al sistema.
Curso Normal

1 UPM, UCP Este caso de uso inicia cuando el Actor va a iniciar sesión en
el sistema
2 SISTEMA El sistema comunica un conjunto de datos
3 UPM, UCP El Actor completa los datos.
4 SISTEMA El sistema verifica los datos ingresados con los registrados en
la Base de Datos
5 SISTEMA El Sistema comunica que los datos son validos
6 SISTEMA El Sistema comunica que el ingreso al sistema fue exitoso
[Se describe el proceso o secuencia de pasos ejecutadas usando frases cortas]
[Cada paso del proceso puede ser ejecutado por los Actores o por el sistema]
[Se describe la secuencia de acciones realizadas por los actores y la secuencia de
actividades realizada por el sistema como respuesta].
Cursos Alternos

5.B El Sistema comunica que los datos NO son validos
6.B El Actor corrige los datos ingresados
7.B El Sistema comunica que los datos son validos
8.B El Sistema permite el ingreso al sistema
9.B Fin del Caso de Uso
REGISTRAR SERVICIOS MEDICOS
Caso de Uso REGISTRAR SERVICIOS Identificador:

[UC-UPM-01]
Actores UPM
Referencias N/A
Precondición El Profesional (UPM) se encuentra activo en el sistema y puede
Registrar servicios
Postcondición El Profesional (UPM) ha Registrado nuevos Servicios
Descripción El Profesional ya se encuentra dentro del sistema y puede realizar el
Registro de los servicios que desea ofrecer.
Curso Normal

1 UPM Este caso de uso inicia cuando el Profesional se encuentra
(activo) dentro del sistema
2 UPM El Profesional ingresa a la opción Registrar Servicios
3 SISTEMA El Sistema comunica un conjunto de datos a completar
4 UPM El Profesional completa el conjunto de datos
5 SISTEMA El Sistema comunica que se ha creado un nuevo Registro
CONSULTAR AGENDA PROGRAMADA
Caso de Uso CONSULTAR AGENDA Identificador:

PROGRAMADA [UC-UPM-02]
Actores UPM
Referencias [UC-UPM-03]
Precondición El Profesional (UPM) se encuentra activo dentro del sistema
Postcondición El Profesional (UPM) ha Consultado su Agenda Programada
Descripción El Profesional ya se encuentra dentro del sistema y puede realizar
consultas sobre cuando han agendado sus servicios médicos ofrecidos.
Curso Normal

2 UPM El Profesional ingresa a la opción Consultar Agenda
3 SISTEMA El Sistema comunica un conjunto de datos a observar
CONSULTAR INFORMACION DETALLADA DE PERSONAS QUE

AGENDARON
Caso de Uso CONSULTAR INFORMACION Identificador:

USUARIOS [UC-UPM-03]
Actores UPM
Referencias [UC-UPM-02]
Precondición El Profesional (UPM) se encuentra activo dentro del sistema
Postcondición El Profesional (UPM) ha Consultado Información detallada de quienes
han solicitado sus servicios
Descripción El Profesional ya se encuentra dentro del sistema y puede realizar
consultas sobre las personas que han solicitado y agendado sus
servicios ofrecidos.
Curso Normal

2 UPM El Profesional ingresa a la opción Consultar Agenda
3 SISTEMA El Sistema comunica un conjunto de datos a observar
BUSCAR PROFESIONAL
Caso de Uso BUSCAR PROFESIONAL Identificador:

[UC-UCP-01]
Actores UCP
Referencias [UC-UCP-02] , [UC-UCP-03]
Precondición El Usuario Cliente Prepagado (UCP) se encuentra activo dentro del
sistema
Postcondición El Usuario Cliente Prepagado (UCP) ha realizado la Búsqueda de un
Profesional de la Salud.
Descripción El Usuario Cliente Prepagado (UCP) se encuentra dentro del sistema
después de haber iniciado sesión y puede realizar la Búsqueda de un
Profesional de la Salud por nombre, tipo de servicio y ubicación.
Curso Normal

1 UCP Este caso de uso inicia cuando el Usuario Cliente Prepagado
se encuentra (activo) dentro del sistema
2 UCP El Usuario Cliente Prepagado ingresa a la opción Buscar
Profesional
3 SISTEMA El Sistema comunica un conjunto de datos desplegables
4 UCP El Usuario Cliente Prepagado Selecciona el conjunto de datos
que desea y oprime el Botón Buscar
5 SISTEMA El Sistema muestra un conjunto de Datos con los nombres de
los Profesionales y su correspondiente Agenda
6 Fin del Caso de Uso
Cursos Alternos

5.B El Sistema muestra un Mensaje de que no se encuentran Agendas
Disponibles con los datos Buscados
6.B El Usuario Cliente Prepagado Selecciona el conjunto de datos que desea y
oprime el Botón Buscar
7.B El Sistema muestra un conjunto de Datos con los nombres de los
Profesionales y su correspondiente Agenda
SELECCIONAR PROFESIONAL
Caso de Uso SELECCIONAR PROFESIONAL Identificador:

[UC-UCP-02]
Actores UCP
Referencias Extends→[UC-UCP-01] , Extends→[UC-UCP-03]
sistema
Postcondición El Usuario Cliente Prepagado (UCP) ha Seleccionado un Profesional
de la Salud y Consultado su Agenda.
después de haber iniciado sesión y puede realizar la Selección de un
Profesional de la Salud por nombre y Agenda Disponible.
Curso Normal

se encuentra (activo) dentro del sistema
2 UCP El Usuario Cliente Prepagado ingresa a la opción Buscar
Profesional
3 SISTEMA El Sistema comunica un conjunto de datos desplegables
4 UCP El Usuario Cliente Prepagado Selecciona el conjunto de datos
que desea filtrar y oprime el Botón Buscar
5 SISTEMA El Sistema muestra un conjunto de Datos con los nombres de
los Profesionales y su correspondiente Agenda
6 UCP El Usuario Cliente Prepagado Selecciona un Profesional con
su correspondiente Servicio Ofrecido y Agenda de Atención
7 SISTEMA El Sistema muestra al usuario el conjunto de Datos
Seleccionado.
Cursos Alternos

5.B El Sistema muestra un Mensaje de que no se encuentran Agendas
Disponibles con los datos Buscados
6.B El Usuario Cliente Prepagado Selecciona el conjunto de datos que desea y
oprime el Botón Buscar
7.B El Sistema muestra un conjunto de Datos con los nombres de los
Profesionales y su correspondiente Agenda
8.B El Usuario Cliente Prepagado Selecciona un Profesional con su
correspondiente Servicio Ofrecido y Agenda de Atención
9.B El Sistema muestra al usuario el conjunto de Datos Seleccionado.
RESERVAR SESION
Caso de Uso RESERVAR SESION Identificador:

[UC-UCP-03]
Actores UCP
Referencias Extends→[UC-UCP-01] , Extends→[UC-UCP-02]
sistema, ha Buscado y seleccionado el Profesional con su respectiva
Agenda.
Postcondición El Usuario Cliente Prepagado (UCP) ha Reservado una Sesión
después de haber iniciado sesión y de haber Seleccionado un
Profesional de la Salud por su nombre y Agenda Disponible. A
continuación, realizara la Reserva de una Sesión.
Curso Normal

ha seleccionado a un profesional de la Salud según su Agenda
correspondiente y tiene 2 opciones Botón Regresar a
Búsqueda o Botón Reservar Sesión.
2 UCP El Usuario Cliente Prepagado oprime el Botón Reservar
Sesión
3 SISTEMA El Sistema comunica un Mensaje de Confirmación.
4 UCP El Usuario Cliente Prepagado Responde Afirmativamente
5 SISTEMA El Sistema Comunica un Mensaje de Reserva de Sesión
Exitosa
Cursos Alternos

2.B El Usuario Cliente Prepagado oprime el Botón Volver a Búsqueda
3.B El Sistema comunica un Mensaje de Confirmación.
4.B El Usuario Cliente Prepagado Responde Afirmativamente
5.B El Usuario Cliente Prepagado Regresa a la Ventana de Buscar Profesional

4.C El Usuario Cliente Prepagado Responde Negativamente
5.C El Sistema Comunica un Mensaje de que NO se ha Reservado ninguna
Sesión
6.C El Sistema Regresa al Curso Normal Nro. 1

1.C El Usuario Cliente Prepagado oprime el Botón Volver a Búsqueda
2.C El Sistema comunica un Mensaje de Confirmación.
3.C El Usuario Cliente Prepagado Responde Negativamente
4.C El Sistema Regresa al Curso Normal Nro. 1
PAGAR EN LINEA

[UC-UCP-04]
Actores UCP
Referencias Extends→[UC-UCP-01] , Extends→[UC-UCP-02], Extends→[UC-
UCP-02], include [UC-UCP-04]
Precondición El Usuario Cliente Prepagado (UCP) ha Reservado Satisfactoriamente
un sesión
Postcondición El Usuario Cliente Prepagado (UCP) ha Pagado una sesión (Sistema
Regresa a la ventana de Buscar Profesional)
Descripción El Usuario Cliente Prepagado (UCP) ha realizado la reserva de una
sesión y a continuación desea realizar el pago de esta. En caso de no
confirmarse el pago el sistema eliminara la Reserva al cabo de 3 horas.
Curso Normal

ha Reservado una sesión
2 SISTEMA El Sistema comunica los Medio de pago de la sesión.
3 UCP El Usuario Cliente Prepagado Realiza la Selecciona del medio
de pago
4 SISTEMA El sistema comunica un conjunto de datos a completar
5 UCP El Usuario Cliente Prepagado Completa el conjunto de datos
y aprueba el pago
6 SISTEMA El sistema comunica un mensaje con la aprobación exitosa del
pago
Cursos Alternos

6.B El sistema comunica un mensaje con la NO aprobación del pago con su
respectivo código de error.
3.B El Sistema Regresa al Curso Normal Nro. 2
MODIFICAR AGENDA

[UC-UCP-04]
Actores UCP
Referencias [UC-UCP-04], include [UC-UCP-05]
Precondición El Usuario Cliente Prepagado (UCP) ha realizado el Pago en Línea de
una sesión. (El sistema se encuentra en la ventana inicial de Buscar
Profesional)
Postcondición El Usuario Cliente Prepagado (UCP) ha modificado una sesión.
Descripción El Usuario Cliente Prepagado (UCP) ha realizado el pago de una
sesión en línea, ahora el sistema habilitara un Botón en la ventana
principal de Buscar Profesional, el Botón tiene el nombre de
Modificar sesión. (Este Botón solamente aparece cuando se ha
realizado el pago de una sesión )
Curso Normal

ha realizado el Pago de una sesión
2 SISTEMA El Sistema Habilita el botón Modificar sesión
SISTEMA El sistema ahora muestra que existe una sesión Agendada
3 UCP El Usuario Cliente Prepagado Oprime el Botón Modificar
sesión
4 SISTEMA El sistema habilita en pantalla la ventana de buscar
Profesional
5 SISTEMA El sistema comunica un conjunto de datos desplegables
6 UCP El Usuario Cliente Prepagado Selecciona los datos de las
listas desplegables
7 SISTEMA El sistema habilita un Botón llamado Guardar
8 UCP El Usuario Cliente Prepagado Oprime el Botón Guardar
9 SISTEMA El sistema comunica un mensaje de Confirmación
10 UCP El Usuario Cliente Prepagado Responde afirmativamente
11 SISTEMA El sistema comunica mensaje de aprobación Modificación
satisfactoria
Cursos Alternos

10.B El Usuario Cliente Prepagado Responde Negativamente
11.B El Sistema Regresa al Curso Normal Nro. 5
REPORTE PROFESIONALES REGISTRADOS
Caso de Uso REPÓRTE REGISTRO Identificador:

PROFESIONALES [UC-SAC-01]
Actores SAC
Referencias N/A
Precondición El Administrador del sistema ha iniciado sesión y se encuentra activo
en la ventana Panel de Administración
Postcondición El Administrador del sistema ha Generado un Reporte a detalle de los
profesionales Registrados
Descripción El Administrador del sistema al iniciar sesión tiene acceso a un panel
de Administración, donde mediante un Botón desplegable, puede
seleccionar entre varias opciones de Reportes.
Curso Normal

1 SAC Este caso de uso inicia cuando Administrador del sistema ha
iniciado sesión
2 SISTEMA El Sistema presenta un panel de Administración con un Botón
desplegable (Generar Reportes)
SAC El Administrador del Sistema oprime el Botón desplegable
(Generar Reportes)
3 SISTEMA El Sistema Comunica un conjunto de datos a Seleccionar
4 SAC El Administrador del Sistema Selecciona la opción Reporte
Profesionales Registrados
5 SISTEMA El Sistema Comunica un conjunto de datos a observar con
información a detalle.
REPORTE USUARIOS CLIENTE PREPAGADO REGISTRADOS
Caso de Uso REPORTE REGISTRO USUARIOS Identificador:

[UC-SAC-02]
Actores SAC
Referencias N/A
Postcondición El Administrador del sistema ha Generado un Reporte a detalle de los
Usuarios Cliente Prepagado Registrados
seleccionar entre varias opciones de Reportes.
Curso Normal

iniciado sesión
(Generar Reportes)
4 SAC El Administrador del Sistema Selecciona la opción Reporte
Usuarios Cliente Prepagado Registrados
DETALLE AGENDA PROFESIONAL ESPECIFICO
Caso de Uso DETALLE AGENDA PROFESIONAL Identificador:

[UC-SAC-03]
Actores SAC
Referencias N/A
Precondición El Administrador del sistema ha Generado un Reporte de los
Profesionales Registrados en el sistema
Postcondición El Administrador del sistema ha Generado un Reporte a detalle de un
Profesional Especifico
seleccionar entre varias opciones de Reportes. El reporte a detalle
Profesional especifico, muestra la agenda del Profesional seleccionado
Curso Normal

1 SAC Este caso de uso inicia cuando el Administrador del sistema
ha Generado un Reporte de los Profesionales Registrados en
el sistema
2 SISTEMA El Sistema presenta un conjunto de datos con los
profesionales Registrados
SAC El Administrador del Sistema selecciona un Profesional de la
Lista desplegable
3 SISTEMA El Sistema presenta un conjunto de datos a detalle con la
Agenda correspondiente al Profesional seleccionado y Botón
llamado Generar Reporte Agenda Profesional
4 SAC El Administrador del Sistema oprime el botón Generar
Reporte Agenda Profesional
5 SISTEMA El Sistema presenta un conjunto de datos a Observar
DETALLE AGENDA USUARIO ESPECIFICO
Caso de Uso DETALLE AGENDA USUARIO Identificador:

[UC-SAC-04]
Actores SAC
Referencias N/A
Precondición El Administrador del sistema ha Generado un Reporte de los Usuarios
Registrados en el sistema
Postcondición El Administrador del sistema ha Generado un Reporte a detalle de un
Usuario Especifico
seleccionar entre varias opciones de Reportes. El reporte a detalle
Usuario especifico, muestra la agenda del Usuario seleccionado
Curso Normal

1 SAC Este caso de uso inicia cuando el Administrador del sistema
ha Generado un Reporte de los Profesionales Registrados en
el sistema
2 SISTEMA El Sistema presenta un conjunto de datos con los Usuarios
Registrados
SAC El Administrador del Sistema selecciona un Usuario de la
Lista desplegable
3 SISTEMA El Sistema presenta un conjunto de datos a detalle con la
Agenda correspondiente al Usuario seleccionado y Botón
llamado Generar Reporte Agenda Usuario
4 SAC El Administrador del Sistema oprime el botón Generar
Reporte Agenda Usuario
5 SISTEMA El Sistema presenta un conjunto de datos a Observar
CONSULTAR SERVICIOS MAS SOLICITADOS
Caso de Uso CONSULTAR SERVICIOS Identificador:

[UC-SAC-05]
Actores SAC
Referencias N/A
Postcondición El Administrador del sistema ha Generado un Reporte llamado:
Consulta a Detalle de Los Servicios más Solicitados
seleccionar entre varias opciones de Reportes. El reporte a seleccionar
es Consulta a Detalle de Los Servicios más Solicitados
Curso Normal

iniciado sesión
(Generar Reportes)
4 SAC El Administrador del Sistema Selecciona la opción: Consulta
a Detalle de Los Servicios más Solicitados
DIAGRAMAS DE SECUENCIAS
Diagrama de Secuencias Funcionalidades Actor Usuario Cliente Prepagado
Ilustración 5. Diagrama de Secuencias UCP parte 1. Elaboración Propia.

Ilustración 6. Diagrama de Secuencias UCP parte 2. Elaboración Propia.
Diagrama de Secuencias Funcionalidades Actor Usuario Profesional Medico
Ilustración 7. Diagrama de Secuencias Funcionalidades Actor UPM. Elaboración Propia.

Diagrama de Secuencias Funcionalidades Actor Administrador del Sistema
Ilustración 8. Diagrama de Secuencias Funcionalidades Actor Administrador del Sistema. Elaboración Propia.
DIAGRAMAS DE ESTADOS
Login
Ilustración 9. Diagrama de Estados -Log in

Registro
Ilustración 10. Diagrama de Estados -Registro

Usuario Cliente Prepagado
Ilustración 11. Diagrama de Estados -UCP

Usuario Profesional Medico
Ilustración 12. Diagrama de Estados -UPM

SUSTENTACION
La sustentación del proyecto se realizará mediante un video donde se expondrán algunas

partes fundamentales del Proyecto. Para ello hemos grabado un video y lo hemos subido a
la plataforma de YouTube.
Enlace video Sustentación https://youtu.be/4e4nMzfPRDw

Administrador
Ilustración 3. Diagrama de Estados -ADMIN

REFERENCIAS
ÁLvarez, F. J., Hurtado Alegría, J. A., Mondragón Arellano, M., Muñoz Arteaga, J.,
Velázquez Amador, C. E., & Hernández Bieliukas, Y. C. (2014, abril). Gestion de
Proyectos de Software. https://www.formacionprofesional.info.
https://www.formacionprofesional.info/wp-content/uploads/2019/04/Gestion-de-
Proyectos-de-Software-LATIn.pdf
Modelo en espiral: el modelo para la gestión de riesgos en el desarrollo de software.
(2020, 17 agosto). IONOS Startupguide.
https://www.ionos.es/startupguide/productividad/modelo-en-espiral/

ENTREGA PROYECTO 3 ESCENARIO 7 Consolidado Grupal Ingeniería de Software

Cargado por

Información del documento

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 PROYECTO 3 ESCENARIO 7 Consolidado Grupal Ingeniería de Software

Cargado por

Copyright:

Formatos disponibles

PROYECTO INGENIERIA DE SOFTWARE 1

POLITECNICO GRANCOLOMBIANO INSTITUCION UNIVERSITARIA

Dar a conocer de manera argumentativa el Modelo de Proceso seleccionado que satisfará

MODELO DE PROCESO EN ESPIRAL VS OTROS MODELOS DE PROCESO

Porque rechazamos el Modelo de Proceso en V o en Cascada

• Primeramente, porque en este Modelo de Proceso se depende de requisitos estable y

• No se promueve la reutilización del software y no se promueve el uso de prototipos,

Porque rechazamos el Modelo de Proceso en Prototipos

Porque rechazamos el Modelo de Proceso Incremental

• Deben existir Desarrolladores muy experimentados quienes entiendan a cabalidad las

Porque seleccionamos el Modelo de Proceso en espiral

• El cliente se sentirá más satisfecho trabajado de la mano del equipo de desarrollo y

• La revisión cíclica puede determinar si desarrollos posteriores van o no a satisfacer

• Los recursos económicos se plantean en cada ciclo, determinado si es viable o no

Desventajas Modelo de Proceso espiral en desarrollo de software

● Agotamiento en procesos que se tornan repetitivos para alcanzar las mejoras en el

• Mala gestión del grupo de trabajo

Mitigación de los Riegos

Para culminar un ciclo de desarrollo en espiral se tienen 4 pasos fundamentales y es aquí

Ilustración 1. Análisis de Requerimientos. Clico de vida del Software

Todas las actividades que intervienen en el desarrollo de un producto de software son

- Acercamiento a una construcción de base de datos.

En esta actividad, se verifica que todos los requerimientos o especificaciones se cumplan a

- Puesta en marcha del producto en versión beta

- Capacitación y acompañamiento a usuarios mientras se establece el producto.

MODELOS VISUALES Y PROTOTIPOS

Director del Proyecto

Directo de Líder de Desarrollador Desarrollador Tester

Jhon Ramírez Edward Méndez Oscar Vargas Lizeth Urrego Santiago

La siguiente imagen representa el cronograma de actividades propuesto:

En principio la especificación de requerimientos funcionales de un sistema debe estar

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

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

Rol de Administrador del Sistema:

• Generar reporte de profesionales de la salud registrados.

DIAGRAMAS DEL SISTEMA

Diagrama de casos de uso:

Ilustración 3. Diagrama de Casos de Uso. Elaboración Propia

Ilustración 4Diagrama de clases. Elaboración Propia

Actor Profesional Identificador:

Nombre Nombre del UPM

Nombre Nombre del UCP

Actor Administrador del Sistema Identificador:

Nombre Nombre del SAC

ESPESIFICACION DE CASOS DE USO

Caso de Uso REGISTRO EN EL SISTEMA Identificador:

Nro. Ejecutor Paso o Actividad

9 Fin del caso de uso

Nro. Descripción de acciones alternas

Caso de Uso LOG IN Identificador:

Nro. Ejecutor Paso o Actividad

Nro. Descripción de acciones alternas

REGISTRAR SERVICIOS MEDICOS

Caso de Uso REGISTRAR SERVICIOS Identificador:

Nro. Ejecutor Paso o Actividad

Caso de Uso CONSULTAR AGENDA Identificador:

Nro. Ejecutor Paso o Actividad

CONSULTAR INFORMACION DETALLADA DE PERSONAS QUE

Caso de Uso CONSULTAR INFORMACION Identificador:

Nro. Ejecutor Paso o Actividad

Caso de Uso BUSCAR PROFESIONAL Identificador:

Nro. Ejecutor Paso o Actividad

Nro. Descripción de acciones alternas