Trabajo Colaborativo Ingeniería Software Parte 3

Trabajo Colaborativo Ingeniería De Software 1
Trabajo Colaborativo Ingeniería De Software
Evis Paez Bolívar Código: 1911023336

Alexandra Acosta Cardona Código: 1821020729
Alexi Danilo Arevalo Betancourt Código: 1811027349
Lizandro Carvajal Ramos Código: 1911028220
Cesar Augusto Uribe Gonzalez Código: 1911025751
Docente: Nelson Orlando Pérez Echeverri
Politécnico Gran colombiano

Facultad de Ingeniería (Bogotá)
Ingeniería de Software
Materia: Ingeniería del software
TABLA DE CONTENIDO
RESUMEN.......................................................................................................................................5
I. INTRODUCCIÓN........................................................................................................................6
II. JUSTIFICACIÓN........................................................................................................................7
III. PRIMERA PARTE.....................................................................................................................8
IV. SEGUNDA PARTE.................................................................................................................18
V. CONCLUCIONES ...................................................................................................................58
REFERENCIAS.............................................................................................................................59
LISTA DE TABLAS
TABLA 1. PERSONAL INVOLUCRADO ..................................................................................18

YTABLA 2. DEFINICIONES ......................................................................................................19
YTABLA 3. REFERENCIAS .......................................................................................................19
YTABLA 4. CARACTERISTICAS DE LOS USUARIOS .........................................................21
YTABLA 5. REQUERIMIETOS FUNCIONALES ...................................................................23
YTABLA 6. REQUERIMIETOS NO FUNCIONALES ............................................................23
YTABLA 7. REQUISITOS NO FUNCIONALES ....................................................................40
YTABLA 8. HISTORIAL DE USUARIOS ..............................................................................43
YTABLA 9. SPRINT .................................................................................................................43
LISTA DE FIGURAS
Fig. 1. Modelo en Espiral …………………………………………………………………………

13
Fig. 2. Fases del Ciclo
Espiral…………………………………………………………………….14
Fig. 3. Diagrama UML Paciente personal .
……………………………………………………….20
Fig. 4. Resultados Sprint...………………. ……………………………………………………….
Fig.5. Diagrama de Clases...……………...……………………………………………………….
Fig.6. Interaccion Login......……………...……………………………………………………….
Fig.7. Interaccion Solicitud Cita Rol Usuario Paciente………………….……………………….
Fig.8. Interaccion Creacion de Agenda Rol Profecional de la Salud……….…………………….
Fig.9. Interfaz Iniciar Sesion ……………………………………………….…………………….
Fig.10. Sistema……………………………………………………….…….…………………….
Fig.8. Registro de Salida …………………………………………..……….…………………….
.
RESUMEN
Con este trabajo se culminan tres entregas del trabajo colaborativo para así afianzar los
conocimientos adquiridos durante el recorrido de la materia y así plasmarlos en esta última
entrega
también se consolida todos los trabajos anteriores para ver el progreso obtenido
Este documento consta de tres secciones. En la primera sección se realiza una introducción al
mismo y se proporciona una visión general de la especificación de recursos del sistema.
En la segunda sección del documento se realiza una descripción general del sistema, con el fin de
conocer las principales funciones que éste debe realizar, los datos asociados y los factores,
restricciones, supuestos y dependencias que afectan al desarrollo, sin entrar en excesivos detalles.
Por último, la tercera sección del documento es aquella en la que se definen detalladamente
los requisitos que debe satisfacer el sistema.
Palabras clave: Afianzar, Trabajo Colaborativo, Plasmarlos, Recurso, Sistema

I. INTRODUCCIÓN
Con este trabajo se pretende seleccionar un modelo de procesos el cual se dio por voto entre los
integrantes del grupo y una buena selección del porque este modelo es el más adecuado para
nuestro trabajo
Así también se justificó el porqué de este mólelo es el más acorde a las necesidades de nuestro
trabajo
Este documento es una Especificación de Requisitos Software (ERS) para el Sistema de consultas
médicas con profesionales de la salud. Esta especificación se ha estructurado basándose en las
directrices dadas por el estándar IEEE Práctica Recomendada para Especificaciones
de Requisitos Software ANSI/IEEE 830, 1998.
II. JUSTIFICACIÓN
El presente documento tiene como propósito definir las especificaciones funcionales, no

funcionales para el desarrollo de un sistema de información web que permitirá gestionar distintos
tipos de servicios médicos con profesionales de alta calidad y eficiencia. Éste será utilizado por
usuarios que requieran un servicio médico a nivel país.
Esta especificación de requisitos está dirigida al usuario del sistema, para continuar con una
mejor atención en cada especialidad de la medicina la cual va a ser consultada de acuerdo a la
necesidad o problema que presenta el paciente, tiene como objetivo principal tener un servicio de
salud a la mano y orientar al paciente hasta el especialista que necesita y así encontrar la solución
inmediata a sus dolencias sin esperar tanto tramite.
III. PRIMERA PARTE
1) Razones por las que se elige el modelo de procesos por prototipo
En principio creo es necesario establecer las condiciones del por qué se debe utilizar e
implementar un modelo de desarrollo de software. Por todos es bien sabido que ante cualquier
proyecto la importancia en su desarrollo y ejecución exitosa depende de múltiples factores, en
especial los organizacionales, lo cuales van desde la planeación, el desarrollo adecuado de las
actividades que se requieran, hasta su culminación teniendo el cuidado de no haber descuidado
ninguno de los aspectos fundamentales de este.
Es qui donde es preciso anotar que desarrollar un software no está muy aparte de lo que es
desarrollar un proyecto, ya que parte desde su construcción, iniciando en la descripción de lo que
se requiere realice o que el cliente manifiesta requiere realice, entender estos requerimientos
hasta finalmente orientarlos a un producto final como lo será nuestro software final y en una
etapa de producción.
Es aquí donde nos permitimos manifestar que un modelo de desarrollo de software nos permitirá
enormemente facilitar temas como como los ya planteados como podrían ser su planeación,
desarrollo y la culminación del mismo. Para esto tomemos en cuenta la definición de
Sommerville, quien plantea que “un modelo del proceso del software es una rep 8resentación
abstracta de un proceso de software donde cada modelo de proceso representa un proceso desde
una perspectiva particular, y así proporciona solo información parcial sobre ese proceso, define
también que los modelos generales no son descripciones definitivas, de los procesos de software,
más bien son abstracciones de los procesos que pueden utilizar para explicar diferentes enfoques
para el desarrollo del software”(aparte tomado de la revista de simulación computacional v2_N5-
2).
2) Justificar la elección del modelo, razones por las que se eligió
En tales condiciones Nuestra escogencia será la del modelo de procesos por prototipo, ya que
como se expondrá a continuación entre las múltiples razones que nos llevan a escoger este
modelo, nos permitimos presentar un compendio de las más importantes, así:
 Es uno de los modelos idóneos para proyectos de investigación como es el caso del
nuestro, ya que no tenemos manera de anticipar el resultado final, esta es una metodología
que nos permite aproximarnos, tener una idea del resultado, pero no ser declarativa, no
deja de lado las características fortuitas que ante este se puedan presentar.
 Nos permite el desarrollo de experimentos, en ambientes controlados, un acercamiento a
la solución. Por decirse de alguna manera “no por el código mismo” si no mas bien por la
interacción con el usuario final o cliente y la experimentación de un posible producto
final.
 En este proceso se da mas importancia a temas como la creatividad, puesto que no hay
lugar a la improvisación, no hace uso de la predicción como elemento fundamental o
principal en su proceso.
 Tiene en cuenta factores que no pueden ser capturados tan fácil y abstraídos del mundo
real, más bien busca que sea el cliente quien los abstraiga y los muestre al programador
mediante la interacción con el o los prototipados.
10
 Las aproximaciones mediante prototipos brindan ir desde un primer intento de producto

final, tomando las ideas que en este primer intento sean valiosas al cliente y al equipo de
trabajo, llevarlas a un segundo intento o tercer intento de ser necesario, depurarlo e irlo
depurando con la evolución del proyecto y a medida que se muestran al cliente. Hasta
llegar a algo que cumpla con las características que específicamente se requieran. Por esto
en su característica se podrían considerar como evolutivos.
 Su progreso y avance es altamente visible tanto para el cliente como para el equipo de
trabajo.
 Es uno de los modelos de proceso con mayor utilidad a la hora de comunicar y definir, así
como de discutir las ideas entre las partes responsables.
 Si el cliente no sabe lo que quiere, al ver algo y su funcionalidad, rápidamente sabrá
identificar lo que no quiere mediante esta metodología, por esta razón se considera a los
prototipos de gran ayuda
 Responde a preguntas y apoyan el trabajo de los diseñadores, probando ideas, clarificando
requisitos o definiendo ideas alternativas.
 Es una metodología ágil y oportuna.
 Alta adaptabilidad a los cambios que el entorno pueda presentar o a requerimientos
cambiantes.
 Las entregas periódicas e incrementales permiten al cliente percibir cierto control sobre el
que será su producto final, lo que genera en él confianza hacia un producto de calidad.
 Que presenta algunas desventajas como la dificultad para establecer el tiempo y costes,
así como altas expectativas en el cliente final, pero que bien manejadas podrían
presentarse como ventajas en un planteamiento de idea de negocio, siendo explotadas a
nuestro favor.
 Las entregas periódicas e incrementales permiten al cliente percibir cierto control sobre el
que será su producto final, lo que genera en la confianza hacia un producto de calidad. Ya
que podría dar la sensación de centrar su importancia en las personas mas que a los
procesos propiamente dichos.
11
 Permite percibir al cliente el trabajo desarrollado y su calidad, ya que lo presenta de

manera ordenada en pasos y fases documentadas, con metodología claras, lejos de lo que
sin querer ser despectivo se podría llamar “practicas artesanales”.
 Permite la detección temprana de defectos, ya que no solo es el equipo de trabajo quien
evalúa la calidad del prototipo si no el mismo usuario o cliente.
 La prueba del producto final se puede hacer innumerables veces antes de encontrarse en
fase de producción.
 Ante un análisis o intervención se permite la identificación clara de partes o etapas.
 Se puede definir fácilmente puntos para su control
 Como una metodología ágil el modelo de procesos por prototipo obedece a los postulados
de Dijkstra, como lo son:
 El coste del desarrollo inicial debe ser relativamente bajo

 El software debe ser fácil de mantener
 Cualquier desarrollo debe de er portable a nuevo hardware
 El software debe hacer lo que el cliente quiere
 El desarrollo de programas mediante top-down y en contraposición a botón-up
 El desarrollo debe seguir un conjunto de pasos formales para descomponer los
problemas grandes.
 Como parte de la metodología ágil obedece a muchas de sus características las cuales se
enumeran a continuación
 Se basarán en heurísticas provenientes de prácticas de producción de código
 Se enfatizarán en los aspectos humanos: individuo y el trabajo en equipo
 Preparación para cambios durante el proyecto
 Reglas y regulaciones impuestas internamente por el equipo de trabajo
 Procesos menos controlados, con pocos principios
 Contrato al interior de los grupos flexible e incluso inexistente
12
 El cliente es parte del desarrollo en todo momento

 Idónea para pequeñas conformaciones de grupos de trabajo (<10), con pocos roles,
más genéricos y flexibles
 Orientadas a proyectos pequeños, y en el mismo lugar
 Menor énfasis en la arquitectura del software se va definiendo y mejorando a lo

largo del proyecto
En síntesis, se valora a los individuos, equipo e interacciones por encima de los procesos y
herramientas, al software en funcionamiento por encima de la documentación excesiva, a la
colaboración con el cliente por encima de contratos suscritos y adaptabilidad en vez de planes
rigurosos.
13
3) También se tomó en cuenta el modelo espiral el cual lo damos a conocer en modo de

comparación para así saber cuál fue el modelo más acorde para nuestro trabajo
3.1) Modelo en espiral
Basados en los requisitos que nos plantea el cliente para el desarrollo del software que necesita,
como ingenieros en Software debemos hallar una solución que satisfaga a nuestro cliente
teniendo cuenta los requisitos que ello requiera.
En cuanto al modelo que debemos utilizar en este caso podríamos iniciar con un modelo de
procesos en espiral el cual es un proceso evolutivo que nos permite hacer entrega de varios
prototipos los cuales pueden ir evolucionando a medida que avanza el tiempo de entrega del
software. En este caso debemos primero que todo tener en cuenta:
 Cada ciclo se empieza identificando los objetivos de la porción correspondiente.
 Debemos formular una estrategia efectiva para resolver las fuentes de riesgos.
 Una vez se resuelven los riesgos se sigue el ciclo en cascada.
 Cada ciclo se completa con una revisión que incluye todo el ciclo anterior y el plan para el
siguiente.
14
En la actualidad este método forma parte de una metodología ágil como lo es la SCRUM, la cual
fue diseñada para proyectos con un cambio rápido de requisitos, así mismo nos permite hacer
entregas agiles ya que los clientes necesitan algo rápido pues las entregas de productos mínimos
viables permite al cliente generar ingresos.
Fig. 1 Modelo en Espiral

El modelo en espiral es una combinación entre el modelo lineal o de cascada y el modelo
iterativo o basado en prototipos. Este se utiliza con éxito en proyectos donde el costo de un fallo
es un gran riesgo, de ahí que su principal aporte sea considerar la gestión de esos riesgos, algo
que en los modelos anteriores ni siquiera se menciona.
En concreto, los proyectos ejecutados con el modelo en espiral empiezan siendo pequeños,
investigando los mayores riesgos que se pueden tolerar, para pasar a agrandarse poco a poco, en
base a elementos clave sobre los que se construyen las siguientes fases de la espiral.
Habitualmente tiene sentido aplicar este método en proyectos grandes, largos, caros y complejos.
En cuanto a su ejecución, el modelo en espiral consiste en seguir ciclos crecientes de cuatro fases
cada uno, que se van realizando siguiendo una forma de espiral. En cada ciclo se pasa por dichas
fases bien definidas, como en el modelo de cascada, pero con capacidad de evolucionar su
complejidad con cada ciclo. Por tanto, se trata de un modelo evolutivo que, conforme avancen los
ciclos, aumentará el tiempo de ejecución, así como el volumen de código fuente desarrollado y la
complejidad de la gestión de riesgos y de la planificación.
15
Fig. 2 Fases del Ciclo Espiral
Las fases por las que pasa cada ciclo de la espiral son:
Planificación. Se determinan los objetivos y el alcance del ciclo que comienza, tras un necesario
ejercicio de investigación. Con cada iteración, se irá incrementando el tamaño de software
entregado y la funcionalidad cubierta.
Análisis de Riesgo. Se evalúa todo aquello que pueda afectar al proyecto según el estado en que
se encuentre y su grado de avance. Para ello, se diseñarán los prototipos que deberán ser
validados en el ciclo.
Implementación. Se desarrolla y valida el software según el alcance acordado, el cual está

íntimamente relacionado y condicionado con el análisis de riesgos anterior.
Evaluación. Antes de proceder a realizar otra vuelta en la espiral, se debe prestar atención a lo
que sucedió en la vuelta anterior. Se debe analizar en detalle si los riesgos detectados
anteriormente ya tuvieron solución. Básicamente, esta fase servirá para determinar el avance del
proyecto y dar pistas de hacia dónde debe enfocarse la próxima iteración.
https://aspgems.com/metodologia-de-desarrollo-de-software-iii-modelo-en-espiral/
16
En cuanto a los riesgos que podemos tener para el desarrollo del presente proyecto uno de los
más importantes seria que nuestro cliente cambie de opinión repentinamente y para mitigar esto
debemos establecer normas con el cliente y realizar un acta donde se establezcan los requisitos y
pautas a seguir, este acuerdo se realiza entre la empresa de desarrollo y el cliente. En esta acta
debemos plasmar el paso a paso de lo que nuestro cliente requiere para evitar contratiempos a
última hora
17
3.2) Razones por las que se descartan las demás opciones de modelo
Utilizamos la del modelo prototipo, ya que para este tipo de trabajo es muy importante
enfocarnos en la parte gráfica, ya que eso facilitara mucho el uso de este software para el cliente
final, además de que este modelo llamado prototipo tiene las ventajas de que el tiempo dinero se
aprovechan al máximo porque ya habiendo echo la puesta en marcha del mismo
Otras de las muchas ventajas que con este modelo podemos ir corrigiendo errores y mejorando
cada vez más nuestro proyecto, además de que el usuario va a poder interactuar, e informar
modificaciones, lo que, a ciencia cierta, nos ahorrara mucho trabajo al momento de terminarlo
3.3) Riesgos asociados a la selección del modelo y proponer acciones de mitigación de estos
riesgos.
Entre los riesgos o desventajas de este modelo, es que el usuario final se desespere y quiera
comenzar a trabar con el prototipo para suplir esa necesidad a pesar de que este solo sea una parte
o avance de cómo podría quedar el producto final
 Al momento de presentar un prototipo, pueden surgir muchos inconvenientes, uno de

ellos es que al momento de realizar la respectiva presentación de nuestro prototipo , a los
clientes finales estos pueden tomarlo como negativo e incluso irse por otros proyectos si l
prototipo en general se encuentra inconcluso, pueden quedar inconformes luego de ver
nuestro proyecto por primera vez además del tiempo que demoraremos explicándole que
ya que es un prototipo no cuenta con todas las funcionalidades que tendrá la versión
completa
 Una acción a tomar en cuenta para este escenario es que al momento de que realizamos la
respectiva presentación de nuestro prototipo, este se encuentre lo más desarrollado
posible, con las funciones básicas funcionales y pensar en todas las incógnitas que
podrían surgir, de esta manera al momento de presentarlo de esta manera puede que los
aspectos a mejorar sean mínimos lo que nos ahorraría mucho tiempo e inversión de dinero
en el proyecto
18
 Requiere que haiga una partición activa para que vea y evalué el avance del prototipo y
que este esté involucrado diciendo las falencias u otros aspectos que se requieran
solucionar, ejemplo la parte gráfica, funciones, optimación, por esto es requerido que el
usuario final este muy involucrado con este proyecto
 Aunque Este no es considerado como un efecto negativo ya que si el usuario está

totalmente involucrado podrá moldear el proyecto y aportar mejores ideas ayudando al
desarrollo del producto final , aunque claro en parte es una gran demanda de tiempo, ya
que tendrá que estar realizando verificaciones y aportes, y probando cada aspecto del
mismo durante el desarrollo, pero al final del día esto valdrá la pena porque el producto a
entregar estará moldeado cumpliendo a la totalidad de su necesidad, y pensada a una
posterior escalabilidad
 Es importante tener en cuenta la falta de experiencia que podemos tener nosotros los
analistas, programadores en actividades de diseño de interfaces de usuario
 Para mitigar esto es necesario que contemos con un excelente equipo de trabajo que todos
trabajemos en armonía siguiendo las pautas, para poder desarrollar un proyecto y pasar
por las faces necesarias para finalmente tener nuestro proyecto totalmente completo
funcional y que cumpla con todos los estándares necesarios para el mismo
 Dicho lo anterior podemos decir que al momento de comparar la efectividad de esta

técnica con las más tradicionales que son (texto y diagramas) tenemos la gran ventaja que
esta nos va a permitir visualizar de manera temprana el producto o partes del mismo, ya
que en esta se puede ver gráficamente la distribución un ejemplo claro el sistema de un
hospital, podemos decir va ventana para las citas tendrá 10 campos, a mostrar la
distribución tamaño y organización de esta, de esta manera el cliente podrá decir si
cambiar tamaño o distribución de la mismas para que el producto final sea más familiar y
tenga el menor número de quejas
Podemos decir que los prototipos nos permiten ver con anticipación visual como quedara el
producto final desde el punto de vista del diseño
19
IV. SEGUNDA PARTE
1) Personal involucrado
Nombre Lizandro Carvajal Ramos

Rol Analista, diseñador y programador
Categoría Profesional TSU-Informática
Responsabilidad Análisis de información, diseño y programación
del SIS-I
Información de Lizandro861213@hotmail.com
contacto
Nombre Evis Páez Bolívar

del SIS-I
Información de evisbolivar@hotmail.com
contacto
Nombre Cesar Augusto Uribe González

del SIS-I
Información de cesaruribe@hotmail.com
contacto
Tabla 1. Personal involucrado
1.2) Definiciones, acrónimos y abreviaturas

20
Nombr Descripción
e
Usuari Persona que usará el sistema para realizar consulta
o medica
ERS Especificación de Requisitos Software
RF Requerimiento Funcional
RNF Requerimiento No Funcional
FTP Protocolo de Transferencia de Archivos
Tabla 2. Definiciones
1.3) Referencias
Titulo del Documento Referencia

Standard IEEE 830 - IEEE
1998
Tabla 3. Referencias
21
Fig. 3 Diagrama UML Paciente, Personal
2.) Características de los usuarios

22
Tipo de usuario Administrador

Formación TSU en Informática
Actividades Control y manejo del sistema en general
Tipo de usuario Profesional en la salud

Formación Medicina general y Especialista
Actividades Facilitar el control sobre cada paciente
Tipo de usuario Administrativo

Formación Áreas administrativas
Actividades Apoya frente a las actividades presenciales prestada
a usuarios
Orienta al usuario o paciente frente al sistema
Facilita las interacciones entre los diferentes actores
Asiste frente a todas las actividades administrativas
Tipo de usuario Paciente

Formación N/A
Actividades Con su información completa tiene acceso a realizar
consulta en la especialidad que requiere.
Tipo de usuario Visitante

Formación NA
Actividades Observa e indaga sobre los servicios que se ofrecen
en el sistema.
Tabla 4. Características de los Usuarios
3.) Restricciones
 Interfaz para ser usada con internet.
 Uso de Dominio (X)
 Lenguajes y tecnologías en uso: HTML, JAVA.
 Los servidores deben ser capaces de atender consultas concurrentemente.
23
 El sistema se diseñará según un modelo cliente/servidor.

 El sistema deberá tener un diseño e implementación sencilla, independiente de la
plataforma o del lenguaje de programación.
.
3.1) Suposiciones y dependencias
 Se asume que los requisitos aquí descritos son estables

 Los equipos en los que se vaya a ejecutar el sistema deben cumplir los requisitos
antes indicados para garantizar una ejecución correcta de la misma
4.) Requisitos Específicos
4.1) Requerimientos Funcionales
Identificación RF01
del
24
requerimiento:
Nombre del Autentificación del profesional en la salud.
Requerimiento:
Características: Los profesionales deberán identificarse con usuario y
contraseña para acceder al sistema.
Descripción del El sistema podrá ser consultado por el profesional para tener
requerimiento: control de sus pacientes y cumplir con las citas ya
programadas
Requerimiento  RNF01
NO funcional:  RNF02
 RNF05
Prioridad del requerimiento:
Alta
del
requerimiento:
Nombre del Autentificación de Paciente.
Requerimiento:
Características: Los Pacientes deberán identificarse con usuario y contraseña
para acceder a cualquier servicio medico.
Descripción del El sistema podrá ser consultado por el paciente dependiendo
requerimiento: del lugar donde se encuentre, del servicio que requiera y su
nivel de accesibilidad.
 RNF05
Alta
del
requerimiento:
Nombre del Registrar Usuarios.
25
Requerimiento:
Características: Los usuarios deberán registrarse en el sistema para acceder a
cualquier parte del sistema.
Descripción del El sistema permitirá al usuario (paciente, profesional y
requerimiento: Administrador) registrarse. El usuario debe suministrar datos
como: Nombre, Apellidos, genero, edad, dirección de
residencia, E-mail, Usuario y Password.
 RNF05
Alta
del
requerimiento:
Nombre del Consultar Información.
Requerimiento:
Características: El sistema ofrecerá al usuario información general acerca de la
medicina general y Medicina especializada, .
Descripción del Medicina General: Muestra información general sobre citas
requerimiento: medicas, disponibilidad del profesional, horarios de atención,
hacer pago en línea modificar la hora y fecha de la cita.
Alta
del
requerimiento:
Nombre del Consultar Información.
Requerimiento:
Características: El sistema ofrecerá al usuario información general acerca de la
medicina general y Medicina especializada.
26
Descripción del Medicina especializada: Muestra información general sobre

requerimiento: citas medicas, disponibilidad del profesional, horarios de
atención, hacer pago en línea modificar la hora y fecha de la
cita.
Alta
del
requerimiento:
Nombre del Modificar.
Requerimiento:
Características: El sistema permitirá al administrador, profesional y paciente
modificar los datos personales, agendar o cancelar citas y
realizar o cancelar los servicios médicos solicitados.
Descripción del Permite al administrador modificar datos de los profesionales
requerimiento: y pacientes y cuentas creadas.
 RNF05
 RFN07
Alta
del
requerimiento:
Nombre del Gestionar Reportes.
Requerimiento:
Características: El sistema permitirá generar reportes.
Descripción del Permite al administrador imprimir reportes de los las
27
requerimiento: consultas medicas realizadas por cada profesional, así como

también, ver listados de pacientes por tipo de patología y la
cantidad de visitas que realizan particulares para conocer de
nuestros servicios
Alta
del
requerimiento:
Nombre del Gestionar reporte.
Requerimiento:
Características: Garantiza al profesional tratante general la formula medica la
cual puede ser impresa por el paciente con su respectiva firma
digital.
Descripción del Permite al profesional de la salud ordenar exámenes de
requerimiento: laboratorios o demás exámenes especializados que tengan
control por orden medica.
Alta
del
requerimiento:
Nombre del Auditoría del sistema
Requerimiento:
Características: Garantizar las soluciones de problemas existentes mediante la
utilización del sistema.
Descripción del Evaluar y analizar los procesos del sistema, proponiendo
requerimiento: solución de problemas existentes dentro del sistema utilizado.
28
 RNF06
 RNF07
Alta
Tabla 5. Requerimientos Funcionales

29
5.) Requerimientos no funcionales.
Identificación RNF01
del
requerimiento:
Nombre del Interfaz del sistema.
Requerimiento:
Características: El sistema presentara una interfaz de usuario sencilla,
amigable para que sea de fácil manejo a los usuarios del
sistema.
Descripción del El sistema debe tener una interfaz de uso intuitiva y sencilla.
requerimiento:
Alta
del
requerimiento:
Nombre del Ayuda en el uso del sistema.
Requerimiento:
Características: La interfaz del usuario deberá de presentar un sistema de
ayuda para que los mismos usuarios del sistema se les faciliten
el trabajo en cuanto al manejo del sistema.
Descripción del La interfaz debe estar complementada con un buen sistema de
requerimiento: ayuda (la administración puede recaer en personal con poca
experiencia en el uso de aplicaciones informáticas).
Alta
del
requerimiento:
Nombre del Mantenimiento.
Requerimiento:
Características: El sistema deberá de tener un manual de instalación y manual
30
de usuario para facilitar los mantenimientos que serán

realizados por el administrador.
Descripción del El sistema debe disponer de una documentación fácilmente
requerimiento: actualizable que permita realizar operaciones de
mantenimiento con el menor esfuerzo posible.
Alta
del
requerimiento:
Nombre del Desempeño
Requerimiento:
Características: El sistema garantizara a los usuarios un desempeño en cuanto
a los datos almacenado en el sistema ofreciéndole una
confiabilidad a esta misma.
Descripción del Garantizar el desempeño del sistema informático a los
requerimiento: diferentes usuarios. En este sentido la información almacenada
o registros realizados podrán ser consultados y actualizados
permanente y simultáneamente, sin que se afecte el tiempo de
respuesta.
Alta
del
requerimiento:
Nombre del Nivel de Usuario
Requerimiento:
Características: Garantizara al usuario el acceso de información de acuerdo al
nivel que posee.
Descripción del Facilidades y controles para permitir el acceso a la
requerimiento: información al personal autorizado a través de Internet, con la
31
intención de consultar y subir información pertinente para

cada una de ellas.
Alta
del
requerimiento:
Nombre del Confiabilidad continúa del sistema.
Requerimiento:
Características: El sistema tendrá que estar en funcionamiento las 24 horas los
7 días de la semana. Ya que es este software estará enlazado a
la WEB para la carga de datos y comunicación entre usuarios.
Descripción del La disponibilidad del sistema debe ser continua con un nivel de
requerimiento: servicio para los usuarios de 7 días por 24 horas, garantizando
un esquema adecuado que permita la posible falla en
cualquiera de sus componentes, contar con una contingencia,
generación de alarmas.
Alta
del
requerimiento:
Nombre del Seguridad en información
Requerimiento:
Características: El sistema garantizara a los usuarios una seguridad en cuanto
a la información que se procede en el sistema.
Descripción del Garantizar la seguridad del sistema con respecto a la
requerimiento: información y datos que se manejan tales sean documentos,
archivos y contraseñas.
Alta
Tabla 6. Requerimientos No Funcionales

32
6.) Requisitos Comunes de las Interfaces
6.1) Interfaces de usuario
La interfaz con el usuario consistirá en un conjunto de ventanas con botones, listas y campos de
textos. Ésta deberá ser construida específicamente para el sistema propuesto.
Interfaces de hardware
Será necesario disponer de equipos de cómputos en perfecto estado con las siguientes
características minimas:
 Adaptadores de red.
33
 Procesador de 1.66GHz o superior.

 Memoria mínima de 1 gb.
 Mouse.
 Teclado.
Interfaces de software
 Sistema Operativo: Windows 10 y Mac OS.

 Explorador: Mozilla o Chrome.
Interfaces de comunicación
Los servidores, clientes y aplicaciones se comunicarán entre sí, mediante protocolos estándares
en internet, siempre que sea posible. Por ejemplo, para transferir archivos o documentos deberán
utilizarse protocolos existentes (FTP u otros convenientes).
7.) Requisitos Funcionales
7.1) Requisito funcional 1
 Autentificación del profesional en la salud: los profesionales

deberán identificarse para acceder a cualquier parte del
sistema.
 El sistema podrá ser consultado por profesional tratante dependiendo

del módulo en el cual se encuentre y su nivel de accesibilidad.
Requisito funcional 2
34
 Autenticación del paciente: El sistema podrá ser consultado

por el paciente dependiendo del lugar donde se encuentre, del
servicio que requiera y su nivel de accesibilidad.
 Usuario y contraseña: Permite el ingreso del usuario al sistema para

acceder a los servicios médicos.
 Registrar Usuarios: El sistema permitirá al usuario (paciente,

profesional y Administrador) registrarse. El usuario debe
suministrar datos como: Nombre, Apellidos, genero, edad,
 dirección de residencia, E-mail, Usuario y Password.
 Consultar información:
 MEDICINA GENERAL: Muestra información general sobre citas

médicas, disponibilidad del profesional, horarios de atención, hacer pago
en línea modificar la hora y fecha de la cita
 Consultar información:
35
 MEDICINA ESPECIALIZADA: Muestra información general sobre citas

médicas, disponibilidad del profesional, horarios de atención, hacer pago
en línea modificar la hora y fecha de la cita.
 Modificar: El sistema permitirá al administrador, profesional y

paciente modificar los datos personales, agendar o cancelar
citas y realizar o cancelar los servicios médicos solicitados.
 Gestionar Reportes: Permite al administrador imprimir

reportes de los las consultas medicas realizadas por cada
profesional, así como también, ver listados de pacientes por
tipo de patología y la cantidad de visitas que realizan
particulares para conocer de nuestros servicios.
 Gestionar Reporte: Garantiza al profesional tratante general la

formula medica la cual puede ser impresa por el paciente con
su respectiva firma digital.
 Auditoría: Evaluar y analizar los procesos del sistema,

proponiendo solución de problemas existentes dentro del
sistema utilizado
36
6.) Requisitos No Funcionales
Identificación RFA01
del
requerimiento:
Nombre del Trazabilidad en los procesos e información
Requerimiento:
Características: La base de datos debe ser clara y permitir acceso
Descripción del El registro de usuario con Nombre completo, sus atributos
requerimiento: adicionales como edad, genero, número de identificación,
dirección, teléfono, correo electrónico, servicio al cual se
37
admite o admisión; en todo momento deberán ser claros y no

presentar ambigüedad por eso se recomienda se especifique
claramente. A fin de que se permita una identificación clara
para cada caso en que se requiera. Lo que asegurara en la base
de datos una trazabilidad, reconocimiento fácil y oportuno de
los usuarios en sus diferentes roles creados en el sistema.

Media alta
del
requerimiento:
Nombre del Notificación automática de evento repetido
Requerimiento:
Características: Un usuario, en el rol de paciente solo podrá registrarse una vez
en el sistema y gestionar un solo servicio del mismo tipo por
dia
Descripción del Una vez se garantice que el usuario fue creado exitosamente en
requerimiento: el sistema, se deberá generar los mecanismos a fin de que un
usuario no se genere doble o mas veces en el sistema.
Así también se podrá mediante advertencia indicar cuantas
veces el usuario a accedido a este servicio, en el evento de
repetirse.

Media alta
del
requerimiento:
Nombre del Limite de caracteres para cada tipo de dato que se maneje
Requerimiento:
Características: Mejor administración de la capacidad de almacenamiento,
38
apoyo a la trazabilidad y registro adecuado.

Descripción del A fin de garantizar una mejor gestión de la capacidad de
requerimiento: operación y del sistema en general, así como de
almacenamiento, se manejarán límites de caracteres, así como
especificación de tipo de caracteres almacenables de
característica en los ítems: nombre, identificación, teléfono,
contacto y en los demás que se puedan presentar y que sean de
manejo libre por el usuario.
Esto también permitiría la minimización de usuarios ficticios y
que podrían consumir recursos importantes del sistema.

Media alta
del
requerimiento:
Nombre del Política de manejo adecuado de datos
Requerimiento:
Características: Implementación de políticas que permitan la protección de
datos de usuarios y personal.
Descripción del Ya que la información que se maneja en esta base de datos, se
requerimiento: podría a llegar a constituir en información de tipo persona y
hasta reservada, es necesario recordar que el manejo de datos,
se hace necesario bajo el amparo de diversas leyes y políticas,
así como de mecanismos y estrategias que se tendrán en cuanta
para cada proceso. Garantizando en todo momento un buen
manejo de ellos.
En todo momento se presumirá la buena fe de los usuarios del
sistema, en lo relacionado a fines y alcances y esto deberá ser
reflejado en una política de buen manejo del medio.

Media alta
39
del
requerimiento:
Nombre del Política de uso y alcance del software
Requerimiento:
Características: El uso y desarrollo del software o producto terminado, se
realizará para los fines pactados de común acuerdo.
Descripción del Se aclara que el uso y alcance del software o producto
requerimiento: terminado. Tendrá como fin los alcances pactados de común
acuerdo.
Vale aclarar que cualquier uso indebido que pudiera darse del
mismo, corresponde a la responsabilidad del tenedor de la
licencia, habiendo de aclararse esta condición en la política de
administración y mantenimiento del mismo, así como en los
manuales que se generen para este fin

Media alta
Tabla 7. Requisitos No Funcionales

40
Requisitos de rendimiento
 Garantizar que el diseño de las consultas u otro proceso no

afecte el desempeño del programa, ya que este debe estar
enlazado la red.
Seguridad
 Garantizar la confiabilidad, la seguridad y el desempeño del

sistema informático a los diferentes usuarios. En este sentido
la información almacenada o registros realizados podrán ser
consultados y actualizados permanente y simultáneamente, sin
que se afecte el tiempo de respuesta.
 Garantizar la seguridad del sistema con respecto a la
información y datos que se manejan tales sean documentos,
archivos y contraseñas.
 Facilidades y controles para permitir el acceso a la

información al personal autorizado a través de Internet, con la
intención de consultar y subir información pertinente para cada
una de ellas.
41
Fiabilidad
 El sistema debe tener una interfaz de uso intuitiva y sencilla

 La interfaz de usuario debe ajustarse a las características del software y
ademas de eso a la web porque debe estar enlazada constantemente.
Disponibilidad
 La disponibilidad del sistema debe ser continua con un nivel de servicio para
los usuarios de 7 días por 24 horas, garantizando un esquema adecuado que
permita la posible falla en cualquiera de sus componentes, contar con una
contingencia, generación de alarmas.
Mantenibilidad
 El sistema debe disponer de una documentación fácilmente actualizable que

permita realizar operaciones de mantenimiento con el menor esfuerzo posible
 La interfaz debe estar complementada con un buen sistema de ayuda (la

administración puede recaer en personal con poca experiencia en el uso de
aplicaciones informáticas).
Portabilidad
 El sistema será implantado bajo la plataforma de Windows y Mac OS.

42
Tabla 8. Historias de
Usuario
43
Tabla 9. Sprint
44
Fig. 4 Resultados Sprint
Fig. 5 Diagrama de Clases

45
V. TERCERA PARTE
1.) Punto uno diagrama de secuencia para las interacciones más importantes de la aplicación
46
Fig. 6 Interacción login

47
Fig. 7 Interacción Solicitud Cita Rol Usuario Paciente

48
Fig. 8 Interacción Creación de Agenda, Rol Profesional de la Salud.
1.2) Roles
49
1.2.1) Equipo de trabajo, hace un trabajo más ágil
Product owner: es la persona que está representando al cliente dentro del equipo de trabajos
principal responsabilidad es expresar claramente la necesidad del cliente dentro del product back
log se puede comprar con un iongeniero de requisitos, luego de tener toda la información este se
la pasa al scrum master y al team developer para que ellos se encarguen de construir esa
necesidad
Tiene la responsabilidad de decir que trabajo necesita y maximizar el valor del producto o
proyecto que esté llevando a cabo esto que se expresa
Scrum máster: es un moderador es el líder del equipo de trabajo, pero no es el encargado de dar
órdenes ni de decir cómo se deben hace las cosas, básicamente va a moderar y ayudar para que el
team develo per o equipo desarrollador pueda entender cuál es la necesidad del cliente y l que el
product owner les ha trasmitido
Development team, equipo de desarrollo se componen de las personas responsables de dar

cumplimiento a los sprint son un equipo auto gestionado y organizado
Son personas capacitadas para dar solución o construir la necesidad que el cliente ha solicitado,
independiente mente de sus roles en el team develover todos son desarrolladores, pero dentro de
estas existen varias funciones
 Desarrolladores
 Testers
 Analistas
 Entre otras funciones dentro de ese equipo de trabajo
 El ciclo de vida de scrum es fácil de entender
50
El producto owner va a definir un documento con la lista de las necesidades del cliente, ese
documento se llama product back log ahí se plantean se plasman las necesidades idas requisitos
que tiene el cliente esas necesidades se las pasa al equipo de desarrollo y al scrum team esto se
hace en una reunión llamada Sprint planig meet que se planean como se va a dar solución a una
primera fase del producto final,
Como resultado de esta reunión tendremos un documento llamado sprint back log , que estas son
tomadas del product back log básicamente consisten en ese conjunto de requisitos que se deben
construir entre 1 y 4 semanas eso se llama sprint ese es el corazón ya que le Sprint corresponde
al proceso de desarrollo o construcción de la necesidad del cliente pero dividida por un producto
incremental , ya que el tiempo de desarrollo es de 1 a 4 semanas dependiendo de las
funcionalidades definidas en el sprint back log
En el sprint intervienen el scrum master y team developer

Los del team developer son los encargados de desarrollar y construir esa necesidad que define el
Sprint
Los del scrum master: se encarga de ayudar y facilitar las cosas para que los del team develo per
puedan trabajar, esa personas también podría hacer parte del team develo per pero como scrum
master tendría que ser el moderador para que ese team develo per entienda muy bien la
necesidad del cliente y les puede ayudar con el complemento de su problema
Uno de las actividades más representativas del scrum son los daily scrum o las reuniones diarias
esas reuniones tiene como objetivo hacer seguimientos diariamente, a todos los procesos que
tengamos dentro del sprint de esta manera se reúnen el scrum master y team developer y se
realizan una serie de preguntas puntuales que son:
 Que se hizo ayer

 Que se hizo hoy
 Que va a hacer mañana
 Que problemas encontró
51
Eso se le pregunta a cada persona dentro del equipo de desarrollo , la idea de la reunión es que
sea muy corta que no pase de los 15 minutos , esto se hace para tener un contexto global para
saber cuál es el estado del sprint esto facilita bastante saber el estado del proyecto y la toma de
decisiones, estas reuniones por lo general son realizadas frente a un tablero donde se definen
todas las actividades y todas las tareas asociadas con los miembros del equipo , se utiliza un
tablero tipo canva por lo general ,para facilitar el entendimiento del Sprint y se garantiza el
principio de trasparencia para que todos miembros del equipo puedan ayudar y aportar
El éxito del proyecto depende básicamente mucho del equipo de desarrollo lo que busca es que
todas las personas puedan tener asignaciones de las cuelas sean responsables y que al yo terminar
mi asignación pueda ayudar a otro compañero para poder dar cumplimiento al objetivo del sprint
y los tiempos definidos al finalizar se hace una nueva reunión que se llama sprint review hay van
a estar involucrados el (product owner el scrum master y el equipo de desarrollo) para verificar
el cumplimiento delas metas y los objetivos del Sprint para así garantizar el cumplimiento la
entrega del producto
Luego de la entrega del producto se hace una reunión que es la retrospectiva del Sprint en esa se
busca analizar los resultados del Sprint anterior y buscar alguna problemática o falencias en el
proceso para así hacer mejoras que puedan aplicar al siguiente Sprint, luego de hacer esto
automáticamente debemos iniciar al nuevo Sprint tomando otras de las funcionalidades del
producto back log para sacar otra vez el Sprint back log
Luego se inicia otra vez el proceso para tener un producto funcional, la idea es que este nuevo
producto funcional se le puede entregar al cliente para que él pueda interactuar, y ver el avance
del proyecto hasta que al finalizar todos los sprint hasta que tengamos el proyecto terminado
52
2.) Diagramas de estado para los objetos relevantes dentro del diseño de la aplicación.
Fig. 9 Interfaz Iniciar Sesion

53
Fig. 10 Sistema
54
3.) Aplicar y sustentar en su diagrama de clases el uso de patrones asignación de
responsabilidades en diseños de software .
Fig. 11 Registro de Salida

55
Se escoge este diagrama de clase ya que el rendimiento es óptimo para lo requerido, todo cumple
con su respectivo rol y secuencia, como se aprecia en el diagrama, todo parte con el cliente que,
al ingresar, dependiendo de sus credenciales este será redirigido a uno de los 4 roles, principales
que son rol administrativo, rol cliente, rol personal de la salud, rol administrador del sistema
En el rol administrativo: encontramos que en este rol es para las personas que se vallan a encargar
de administrar la clínica tomas de decisiones de carácter institucional adicional este es el único
capaz de eliminar usuarios posterior mente al ingresar con este rol administrativo podrá registrar
usuarios ver ordenes e historiales clínicos
En el rol cliente: el cliente es un paciente o usuario potencial que posteriormente ingresara y

consumirá los servicios luego de que se realice el respectivo registro ya no sería un cliente si no
que sería un paciente que podría, calcular el total del costo del servicio, buscar su historial clínico
y ver su registro de atención, también puede pedir citas ya sea presencialmente o por su aplicativo
web
Reserva /registro: posterior mente al registro o al inicio de sesión en esta ventana se ingresará la
identificación del paciente, código de historia clínica, fecha y hora luego se verifica la reserva,
disponibilidad y se registra al paciente en la agenda
Pago: después de gestionar la cita se procederá al pago, para esto se tomarán encuentra la
identificación del paciente, código historia clínica se verifica el pago y se habilitara la prestación
del servicio
Prestación servicio: luego de hacer el pago se habrá generado un un código de servicio

Rol profesional de la salud: será los que recojan la historia clínica del paciente formularios y
notas, también podrán reservar /registrar y prestar servicios profesiones
Rol administrador del sistema: en este rol se loguen el administrador el cual se encarga de
gestionar los usuarios, recursos físicos, y las Agendas Del Centro
56
Como se evidencia en el diagrama a cada una de las funciones es subsecuente de la otra es decir
si falla una función no se cae toda la infraestructura mientras se realiza la corrección del servicio,
el diseño de este diagrama tiene unos puntos excelentes de acuerdo a la seguridad ya que como se
observa en el diagrama cada persona se logue y según su usuario y contraseña se le asigna un rol,
es decir una persona de la salud, no tendrá acceso a la información que maneja el administrador,
y un cliente no podrá ver los historiales clínicos de otros, gracias a la asignación de roles que se
dio .
57
V. CONCLUSIONES
Mediante este trabajo pudimos aclarar diferentes conceptos, relacionados a la carrera de

Ingeniería de Sistemas.
Además de ello se enfatizo en el trabajo en equipo para logar así el compendio de toda la
información necesaria para alcanzar el logro de la tercera entrega
58
REFERENCIAS
[[1] “Ventajas y Desventajas del Uso de Prototipos - Gazafatonario IT”.

http://www.gazafatonarioit.com/2012/07/ventajas-y-desventajas-del-uso-de.html (accedido sep.
25, 2020).
[2] “Beneficios principales de los prototipos en el proceso de diseño”.
https://blog.aulaformativa.com/beneficios-principales-prototipos-proceso-de-diseno/ (accedido
sep. 25, 2020).
[3] J. P. Zumba, “Evolución de las Metodologías y Modelos utilizados en el Desarrollo de
Software”, INNOVA Res. J., vol. 3, no 10, pp. 20–33, 2018, doi:
10.33890/innova.v3.n10.2018.651.
[4] A. Gonzalez-lópez, “Revista de Simulación Computacional Aplicación del modelo de
prototipos : Caso de estudio Software RedbotGamesShop Application of the prototype model :
Case study RedbotGamesShop Software Revista de Simulación Computacional”, vol. 2, n o 5, pp.
8–13, 2018.
[5] F. Alonso y L. Socha, Ingeniería de software 1, Fondo edit. Bogotá D.C., 2017.
[6] “Historias de Usuario Scrum - Uso, ejemplos, plantillas con las que trabajar”.
http://urtanta.com/historias-de-usuario/ (accedido sep. 29, 2020).
[7] “User Story Mapping como primer paso para empezar un proyecto SCRUM”.
https://urtanta.com/user-story-mapping/ (accedido sep. 29, 2020).
[8] “(9) (PDF) Una guía para el CUERPO DE CONOCIMIENTO DE SCRUM (Guía
SBOKTM) 3ra Edición Una guía integral para la entrega de proyectos utilizando Scrum | Leonardo
Stracquadaini - Academia.edu”.
https://www.academia.edu/38937062/Una_guía_para_el_CUERPO_DE_CONOCIMIENTO_DE
_SCRUM_Guía_SBOK_3ra_Edición_Una_guía_integral_para_la_entrega_de_proyectos_utilizan
do_Scrum (accedido sep. 29, 2020).
59

Trabajo Colaborativo Ingeniería Software Parte 3

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Trabajo Colaborativo Ingeniería Software Parte 3

Încărcat de

Drepturi de autor:

Formate disponibile

Trabajo Colaborativo Ingeniería De Software 1

Trabajo Colaborativo Ingeniería De Software

Evis Paez Bolívar Código: 1911023336

Docente: Nelson Orlando Pérez Echeverri

Politécnico Gran colombiano

III. PRIMERA PARTE.....................................................................................................................8

IV. SEGUNDA PARTE.................................................................................................................18

TABLA 1. PERSONAL INVOLUCRADO ..................................................................................18

Fig. 1. Modelo en Espiral …………………………………………………………………………

Palabras clave: Afianzar, Trabajo Colaborativo, Plasmarlos, Recurso, Sistema

El presente documento tiene como propósito definir las especificaciones funcionales, no

III. PRIMERA PARTE

1) Razones por las que se elige el modelo de procesos por prototipo

2) Justificar la elección del modelo, razones por las que se eligió

 Las aproximaciones mediante prototipos brindan ir desde un primer intento de producto

 Permite percibir al cliente el trabajo desarrollado y su calidad, ya que lo presenta de

 El coste del desarrollo inicial debe ser relativamente bajo

 El cliente es parte del desarrollo en todo momento

 Menor énfasis en la arquitectura del software se va definiendo y mejorando a lo

3) También se tomó en cuenta el modelo espiral el cual lo damos a conocer en modo de

3.1) Modelo en espiral

Fig. 1 Modelo en Espiral

Fig. 2 Fases del Ciclo Espiral

Implementación. Se desarrolla y valida el software según el alcance acordado, el cual está

 Al momento de presentar un prototipo, pueden surgir muchos inconvenientes, uno de

 Aunque Este no es considerado como un efecto negativo ya que si el usuario está

 Dicho lo anterior podemos decir que al momento de comparar la efectividad de esta

IV. SEGUNDA PARTE

Nombre Lizandro Carvajal Ramos

Nombre Evis Páez Bolívar

Nombre Cesar Augusto Uribe González

Tabla 1. Personal involucrado

1.2) Definiciones, acrónimos y abreviaturas

Titulo del Documento Referencia

Fig. 3 Diagrama UML Paciente, Personal

2.) Características de los usuarios

Tipo de usuario Administrador

Tipo de usuario Profesional en la salud

Tipo de usuario Administrativo

Tipo de usuario Paciente

Tipo de usuario Visitante

Tabla 4. Características de los Usuarios

 El sistema se diseñará según un modelo cliente/servidor.

 Se asume que los requisitos aquí descritos son estables

4.) Requisitos Específicos

4.1) Requerimientos Funcionales

Descripción del Medicina especializada: Muestra información general sobre

requerimiento: consultas medicas realizadas por cada profesional, así como

Tabla 5. Requerimientos Funcionales

5.) Requerimientos no funcionales.

de usuario para facilitar los mantenimientos que serán

intención de consultar y subir información pertinente para

Tabla 6. Requerimientos No Funcionales

6.) Requisitos Comunes de las Interfaces

6.1) Interfaces de usuario

 Procesador de 1.66GHz o superior.

 Sistema Operativo: Windows 10 y Mac OS.

7.) Requisitos Funcionales

7.1) Requisito funcional 1

 Autentificación del profesional en la salud: los profesionales

 El sistema podrá ser consultado por profesional tratante dependiendo

 Autenticación del paciente: El sistema podrá ser consultado

 Usuario y contraseña: Permite el ingreso del usuario al sistema para