Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
TABLA DE CONTENIDO
RESUMEN.......................................................................................................................................5
I. INTRODUCCIÓN........................................................................................................................6
II. JUSTIFICACIÓN........................................................................................................................7
V. CONCLUCIONES ...................................................................................................................58
REFERENCIAS.............................................................................................................................59
Trabajo Colaborativo Ingeniería De Software 3
LISTA DE TABLAS
LISTA DE FIGURAS
.
Trabajo Colaborativo Ingeniería De Software 5
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.
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.
Trabajo Colaborativo Ingeniería De Software 7
II. JUSTIFICACIÓN
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.
Trabajo Colaborativo Ingeniería De Software 8
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,
Trabajo Colaborativo Ingeniería De Software 9
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).
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.
Trabajo Colaborativo Ingeniería De Software
10
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.
Trabajo Colaborativo Ingeniería De Software
11
Como una metodología ágil el modelo de procesos por prototipo obedece a los postulados
de Dijkstra, como lo son:
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
Trabajo Colaborativo Ingeniería De Software
12
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.
Trabajo Colaborativo Ingeniería De Software
13
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.
Trabajo Colaborativo Ingeniería De Software
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.
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.
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/
Trabajo Colaborativo Ingeniería De Software
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
Trabajo Colaborativo Ingeniería De Software
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
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
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
1) Personal involucrado
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
Tabla 3. Referencias
Trabajo Colaborativo Ingeniería De Software
21
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.
Trabajo Colaborativo Ingeniería De Software
23
Identificación RF01
del
Trabajo Colaborativo Ingeniería De Software
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
Identificación RF02
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.
Requerimiento RNF01
NO funcional: RNF02
RNF05
Prioridad del requerimiento:
Alta
Identificación RF03
del
requerimiento:
Nombre del Registrar Usuarios.
Trabajo Colaborativo Ingeniería De Software
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.
Requerimiento RNF01
NO funcional: RNF02
RNF05
Prioridad del requerimiento:
Alta
Identificación RF04
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.
Requerimiento RNF01
NO funcional: RNF02
Prioridad del requerimiento:
Alta
Identificación RF05
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.
Trabajo Colaborativo Ingeniería De Software
26
Identificación RF06
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.
Requerimiento RNF01
NO funcional: RNF02
RNF05
RFN07
Prioridad del requerimiento:
Alta
Identificación RF07
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
Trabajo Colaborativo Ingeniería De Software
27
Identificación RF08
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.
Requerimiento RNF01
NO funcional: RNF02
Prioridad del requerimiento:
Alta
Identificación RF09
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.
Requerimiento RNF03
Trabajo Colaborativo Ingeniería De Software
28
NO funcional: RNF04
RNF06
RNF07
Prioridad del requerimiento:
Alta
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:
Prioridad del requerimiento:
Alta
Identificación RNF02
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).
Prioridad del requerimiento:
Alta
Identificación RNF03
del
requerimiento:
Nombre del Mantenimiento.
Requerimiento:
Características: El sistema deberá de tener un manual de instalación y manual
Trabajo Colaborativo Ingeniería De Software
30
Identificación RNF04
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.
Prioridad del requerimiento:
Alta
Identificación RNF05
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
Trabajo Colaborativo Ingeniería De Software
31
Identificación RNF06
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.
Prioridad del requerimiento:
Alta
Identificación RNF07
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.
Prioridad del requerimiento:
Alta
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.
Trabajo Colaborativo Ingeniería De Software
33
Interfaces de software
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).
Requisito funcional 2
Trabajo Colaborativo Ingeniería De Software
34
Requisito funcional 3
Requisito funcional 4
Consultar información:
Requisito funcional 5
Consultar información:
Trabajo Colaborativo Ingeniería De Software
35
Requisito funcional 7
Requisito funcional 8
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
Trabajo Colaborativo Ingeniería De Software
37
Identificación RFA02
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.
Identificación RFA03
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,
Trabajo Colaborativo Ingeniería De Software
38
Identificación RFA04
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.
Identificación RFA05
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
Requisitos de rendimiento
Fiabilidad
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
Portabilidad
Tabla 8. Historias de
Usuario
Trabajo Colaborativo Ingeniería De Software
43
Tabla 9. Sprint
Trabajo Colaborativo Ingeniería De Software
44
V. TERCERA PARTE
1.) Punto uno diagrama de secuencia para las interacciones más importantes de la aplicación
Trabajo Colaborativo Ingeniería De Software
46
1.2) Roles
Trabajo Colaborativo Ingeniería De Software
49
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
Desarrolladores
Testers
Analistas
Entre otras funciones dentro de ese equipo de trabajo
El ciclo de vida de scrum es fácil de entender
Trabajo Colaborativo Ingeniería De Software
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
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:
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
Trabajo Colaborativo Ingeniería De Software
52
2.) Diagramas de estado para los objetos relevantes dentro del diseño de la aplicación.
Fig. 10 Sistema
Trabajo Colaborativo Ingeniería De Software
54
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
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
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
Trabajo Colaborativo Ingeniería De Software
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 .
Trabajo Colaborativo Ingeniería De Software
57
V. CONCLUSIONES
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
Trabajo Colaborativo Ingeniería De Software
58
REFERENCIAS