Ent1ProyAulEstDat2015 Up

Propuesta de Software “Downtime”
Entrega 1 del Proyecto de Aula: Estructuras de Datos
EXTRACTO
Descripción General de la propuesta de trabajo para la construcción de producto de
software e identificación de los diferentes requerimientos para su desarrollo. Incluye
una propuesta de GUI. Presentado al tutor del Módulo Ing. Nelsón Orlando Pérez
Echeverri. Politécnico Grancolombiano. Septiembre 14 de 2015.
PRIMERA ENTREGA
PROYECTO DE AULA
ESTRUCTURAS DE DATOS - 20152
TABLA DE CONTENIDO
Primera Entrega.................................................................................. 2
Introducción...............................................................................................2
1. Integrantes...........................................................................................3
2. Nombre del proyecto.............................................................................3
3. Objetivos..............................................................................................3
4. Resultados esperados............................................................................3
5. Descripción...........................................................................................4
6. Aplicabilidad de los temas del módulo....................................................5
7. Requerimientos funcionales...................................................................6
INTRODUCCIÓN
De acuerdo a lo solicitado en la primera entrega del “Proyecto de Aula” del módulo de “Estructuras
de Datos” el propósito esperado es la definición de los objetivos y metas del proyecto, estableciendo los
requerimientos funcionales del producto y hacer un análisis del problema; enuncia, para cada funcionalidad,
sus precondiciones y sus pos condiciones junto a una estrategia de solución.
Así mismo, el presente documento define lo que se quiere lograr con el desarrollo del proyecto y si es
viable la implementación del proyecto en las semanas que dura el módulo. Por otra parte, muestra ¿Qué se
tendrá como resultado del proyecto? Liado al relato, en lenguaje natural, de lo que debería hacer el software
a construir. Es decir, una lista de servicios que ofrecerá al usuario el producto final y la interacción con el
usuario a través de una interfaz gráfica. Se describir á́ en forma detallada las interfaces de usuario, de
software y los requerimientos del problema objeto de análisis como de los correspondientes atributos del
sistema.
Antes de esto, el presente trabajo ilustra ¿Cómo se piensa vincular el contenido del módulo con el
desarrollo del proyecto? Para el presente trabajo, se requiere presentar, por parte del grupo de trabajo, 3
informes de progreso. Los informes a entregar son: primer entrega (14 de septiembre): Identificar el
problema y contextualizarlo; segunda entrega (28 de septiembre): describirlo con casos de uso y
pseudocódigos; Informe final (12 de octubre): diseño final de la propuesta y entrega del producto de
software (incluida sustentación).
Con relación a la especificación de requerimientos de software (SRS) del sistema a construir, el
propósito principal es el de contener la información necesaria que ayude, posteriormente, en la fase de
desarrollo del software; que sirva como herramienta para el análisis y comprensión de todos los requisitos y
requerimientos que se esperan obtener en el desarrollo del presente trabajo académico de Estructuras de
datos. Que describa lo que el realmente se desea obtener, y poder lograr tener un documento necesario
cuya información sirva para el desarrollo del software, es decir en la codificación correcta del mismo.
1. NOMBRE DEL PROYECTO.
“Downtime”.
1.1. Descripción General del Proyecto
Sistema para la solicitud de un servicio de atención basado en turnos, denominado “Downtime”,
mediante un aplicativo de Software, codificado en lenguaje de Programación JAVA y utilizando diversas
estructuras de Datos.
2. OBJETIVOS.
2.1. Objetivo General
- Desarrollar un sistema de software que permita la gestión de servicio por turnos de
disponibilidad, a través de la utilización de diferentes estructuras de datos que permitan
la manipulación de la información.
2.2. Objetivos específicos

- Aprender la construcción de algoritmos que incluyan estructuras de datos (listas.
sistemas circulares, listas enlazadas, arboles binarios, grafos, entre otros) y aplicarlos en
la construcción del proyecto de software.
- Identificar los recursos y herramientas para desarrollar un correcto proceso de modelado,
siguiendo cada una de las fases del proceso de construcción de software, así como de su
presentación y preparación de informes a través del estándar UML.
- Desarrollar una implementación que satisfaga los requerimientos funcionales y no
funcionales.
3. RESULTADOS ESPERADOS.
Se espera que al terminar las 6 semanas de duración de la actividad, se pueda contar con un
sistema de software que permita la gestión de solicitudes de servicio, basado en turnos de las enfermeras
de una clínica de reposo. Este producto contará, además, con un documento de modelado a partir de los
“casos de uso” y algunas herramientas del estándar UML.
Adicionalmente, se trabajan algunas estructuras de datos, a fin de evidenciar el conocimiento y
manejo de algoritmos para casos específicos de manipulación de información, por lo que, durante las fases
posteriores, se harán mejoras y adaptación para vincular los conocimientos adquiridos en el desarrollo del
módulo de “Estructuras de Datos”, para poder incluirlos en el producto de software final.
La idea, es lograr la completitud de la propuesta. Es decir, lograr dar una respuesta eficiente a los
diferentes requerimientos solicitados en la presente fases de análisis. Por un lado, respecto a los
requerimientos funcionales y no funcionales, como a la presencia de una interfaz gráfica que permita la
interacción con el usuario.
4. DESCRIPCIÓN.
De acuerdo a los enunciados propuestos por el profesor, el grupo ha decidido tomar como selección
el enunciado numero dos que dice lo siguiente:
Enunciado 2
En una Casa de Reposo se debe permitir a un médico solicitar una enfermera para
atender a un paciente. Como no es muy usual esto, las enfermeras están organizadas
de manera que en todo momento solo haya una disponible.
Cada enfermera se identifica por su nombre y tiene asignado en minutos la duración

de su turno. La enfermera que está de turno, sabe además el tiempo que le falta para
terminar su turno y si está ocupada con un paciente.
Los turnos de las enfermeras están organizados de manera circular.
Al principio no había ni tantos pacientes, ni médicos, ni enfermeras y se llevaba a

mano la bitácora con ayuda del tradicional reloj de pared, pero ahora se necesita de
un sistema más automático.
Los doctores requieren saber cuántas enfermeras hay en el hospicio, conocer cual
está de turno, indicar cuánto le falta a una enfermera (dado su id) para comenzar su
turno. Ocupar a la enfermera de turno con un paciente (retorna la enfermera de turno
si no está ocupada, o null en caso contrario); la enfermera se libera al terminar la
atención (la enferma de turno que estaba ocupada atendiendo a un paciente queda de
nuevo disponible, salvo que su turno haya terminado en cuyo caso pasa a la última
posición, si no estaba ocupada informa del error).
El sistema debe avanzar turno un minuto, de tal suerte que la enfermera que está de
turno disminuye el tiempo que le falta en 1. Si llega a 0, se inicia el turno de la
siguiente enfermera que no esté ocupada con paciente, pasando la que salió de turno
a ocupar la última posición.
Además, las enfermeras por supuesto entran y salen de trabajar de acuerdo con la
necesidad de la entidad, de tal suerte que al ingresar al trabajo una enfermera se
coloca en la última posición y al salir la enfermera del asilo se retira del sistema
circular.
En resumen, a continuación presentamos la descripción particular que se hace de la misma referencia, con
las correspondientes consideraciones, cambios, o comprensiones que se tienen del ejercicio.
El propósito es construir un sistema para la solicitud, por parte de un doctor, de una
enfermera para la atención de un paciente.
Como podemos observar, tenemos tres sujetos (actores) que intervienen en este concepto: Doctor,
enfermera, paciente; y por tanto debe existir un registro de doctores, de enfermeras y de pacientes. En el
caso de las enfermeras,
cada enfermera se identifica por su nombre y tiene asignado en minutos la duración
de su turno.
Mientras que los pacientes, tienen asociados un pabellón y una habitación. Los doctores un nombre.
Estimamos que el turno de la enfermera dura 8 horas, lo que equivale a 480 minutos en turno y un
descanso de 960 minutos. Ahora, del numero de enfermeras que están de turno,
están organizadas de manera que en todo momento solo haya una disponible y sus
turnos están organizados de manera circular.
Por otra parte, el sistema debe permitir conocer cierta información, tal como:
La enfermera de turno, sabe además el tiempo que le falta para terminar su turno
La enfermera de turno, sabe si está ocupada con un paciente.
Los doctores requieren saber cuántas enfermeras hay en el hospicio,

Los doctores requieren conocer cual está de turno,
Los doctores requieren saber cuánto le falta a una enfermera (dado su id) para
comenzar su turno.
Los doctores y las enfermeras requieren saber si ha cambiado el estado de

disponibilidad de una enfermera en particular (Ocupar a la enfermera de turno con un
paciente)
Para dicha gestión de estados, el sistema muestra la enfermera disponible, las que están en turno y las que
están de descanso. Para una mejor comprensión del siguiente párrafo,
retorna la enfermera de turno si no está ocupada, o null en caso contrario; la

enfermera se libera al terminar la atención (la enferma de turno que estaba ocupada
atendiendo a un paciente queda de nuevo disponible, salvo que su turno haya
terminado en cuyo caso pasa a la última posición, si no estaba ocupada informa del
error).
Vamos a considerar los siguientes aspectos:
El doctor hace la solicitud de la enfermera que tiene estado disponible, la cual acepta
el servicio y cambia su estado a “ocupada”. La siguiente enfermera de turno, pasa a
estado “disponible”. Al terminar el servicio, la enfermera que estaba ocupada pasa al
final de la lista de enfermeras de turno hasta que concluya dicho turno. Cuando una
enfermera entra, cambia su estado “de descanso” a “en turno” (ver nota siguiente) y
ocupa el final de la lista de turnos en espera de “disponible”.
Nota: Además, las enfermeras por supuesto entran y salen de trabajar de acuerdo con
la necesidad de la entidad, de tal suerte que al ingresar al trabajo una enfermera se
coloca en la última posición y al salir la enfermera del asilo se retira del sistema
circular
Por otro lado, el sistema gestiona el tiempo, tanto para los turnos como para indicar la hora de acuerdo a los
siguientes criterios:
Al principio no había ni tantos pacientes, ni médicos, ni enfermeras y se llevaba a

mano la bitácora con ayuda del tradicional reloj de pared, pero ahora se necesita de
un sistema más automático.
El sistema debe avanzar turno un minuto, de tal suerte que la enfermera que está de
turno disminuye el tiempo que le falta en 1. Si llega a 0, se inicia el turno de la
siguiente enfermera que no esté ocupada con paciente, pasando la que salió de turno
a ocupar la última posición.
Para este último aspecto, las enfermeras que están “en descanso”, ocupan la posición “en turno” cuando
una enfermera termina su turno y cambia su estado a “en descanso”.
5. APLICABILIDAD DE LOS TEMAS DEL MÓDULO.

Como ya se ha expuesto anteriormente, la idea central del presente proyecto
es trabajar diversas estructuras de datos (en memoria principal). Por ejemplo,
manejo de listas (arreglos) en el caso de los datos obtenidos. Sistemas circulares
como se expresa en la forma en que están organizados los turnos y disponibilidades
de las enfermeras.
Así mismo, se hará uso de algoritmos de búsqueda, ordenamiento, vectores y
matrices, Arboles binarios y n-arios, grafos, entre otros. Para algunas
funcionalidades, utilizaremos pilas o colas según el caso; bien sea, porque una
enfermera deja de atender un paciente y vuelve al final del grupo; o porque va
siguiéndose en turno un grupo, el cual esta mediado por factores temporales.
Desde luego, y algo que va muy ligado a las estructuras de datos, son los
algoritmos, ya que estos permitirán manejar la información, recuperarla
transformarla y/o modificarla, agregar y o eliminar registros, entre otros.
6. REQUERIMIENTOS FUNCIONALES.
El sistema que se va ha desarrollar es independiente, y tendr á́ un diseño modular para gestionar cuatro
aspectos de una clínica de reposo: Consultas, Registro, Estados y Solicitudes. Estos son los cuatro ejes
principales del sistema, en orden de importancia.
Registro Estados Solicitud Consultas

Así mismo, la funcionalidad del producto plantea la siguiente estructura:
Downtime
Gestión de Registro Asignacion

turnos personas es
Control de Enfermera Solicitud

estados s servicios
Consulta
de Aceptacion
Pacientes
informació servicios
n
Mostrar Terminacio
tiempo Doctores n servicios
Se han establecido como actores del sistema los siguientes (el actor paciente no tiene interacción con el
sistema y por tanto no tiene numeración):
Actor Enfermera # 001

Casos de Aceptar solicitud, Terminar atención, Consultar tiempo para
Uso terminar turno, Conocer Estado
Tipo Secundario
Descripción Es una actor importante respecto a la interacción, sin embargo,
no realiza ninguna gestión en el sistema. Usa el sistema como
medio de consulta y acepta y termina solicitudes.
Condiciones Estar registrada en el sistema
especiales
Actor Doctor # 002

Casos de Enviar solicitud, Registrar paciente, Registrar enfermera, Auto
Uso registro, Consultar enfermera, Consultar Tiempo de enfermera
por entrar a turno, Contar enfermeras en turno, Contar total
enfermeras.
Tipo Primario
Descripción Es el actor principal, lleva el registro y gestiona la información
del sistema, además que envía solicitudes y puede consultar
cualquier información que se haya generado.
Condiciones
especiales
Actor Paciente
Casos de Ninguno (no tiene interacción con el sistema)
Uso
Tipo
Descripción
Condiciones
especiales
Actor Esquema de Turno # 003

Casos de Ingresar enfermera al turno, cambiar estado a “disponible”,
Uso cambiar estado a “ocupado”, cambiar estado a “en descanso”,
Tipo Principal
Descripción Es un medio de consulta de información que, además, lleva el
registro de las enfermeras indicando el estado en que se
encuentra en el sistema y hace los cambios respectivo de
acuerdo al tiempo o a las solicitudes dadas por el doctor.
Condiciones Estar relacionado con una misma unidad de medida de tiempo
especiales (reloj).
Trabaja en minutos.
Dentro de los requerimientos no funcionales encontramos
Actor Reloj
Casos de Mostrar Tiempo
Uso
Tipo No esencial
Descripción Muestra el día y la hora, a fin de simular el esquema de trabajo
que existía antes de la automatización del sistema.
Condiciones Ninguna
especiales
Los siguientes son los requisitos específicos del sistema:

# requerimiento RF001 Nombre Registrar Persona (Doctor).
Tipo Requisito Restricción
Fuente Arreglo de Registros de la clase Doctor
Prioridad Alta Media Baja
Introducción
Precondiciones Haber abierto la ventana principal del sistema
Procesos Desde la ventana principal damos clic en el icono registro y se despliega una
ventana de selección con 4 opciones (persona, paciente, doctor, cancelar). Se da
clic en el icono doctor y se despliega un formulario. Se diligencian los datos
correspondientes al doctor y damos clic en aceptar.
Pos condiciones El campo nombre no puede estar vacío.
Excepciones Si el campo nombre está vacío, enviar un mensaje de error “el campo nombre no
puede estar vacío.”
# requerimiento RF002 Nombre Registrar Persona (Enfermera).

Fuente Arreglo de Registros de la clase Enfermera
Introducción Incluir los datos de la enfermera en una matriz, agregando una fila por cada registro
nuevo.
clic en el icono Enfermera y se despliega un formulario. Se diligencian los datos
correspondientes a la enfermera y damos clic en aceptar.
Pos condiciones Los campos nombre, id y turno, no pueden estar vacíos.
Excepciones Si alguno de los campos está vacío, enviar mensaje de error “Campos no pueden
estar vacíos.”
# requerimiento RF003 Nombre Registrar Persona (Paciente).

Fuente Arreglo de Registros de la clase paciente
Introducción
clic en el icono paciente y se despliega un formulario. Se diligencian los datos
correspondientes al paciente y damos clic en aceptar.
Guarda en un arreglo de datos.
Pos condiciones Los campos nombre, pabellón y habitación, no pueden estar vacíos.
Excepciones Si alguno de los campos está vacío, enviar mensaje de error “Campos no pueden
estar vacíos.”
# requerimiento RF004 Nombre Cambiar estado (en descanso).

Fuente
Introducción
Precondiciones Estar registrada en el sistema
Haber finalizado el turno (contador 480)
No tener estado de “Ocupada”.
Procesos Cuando el contador de tiempo en turno (480) llega a 0, cambia la definición estado
a “en descanso” y empieza el siguiente contador (960) a decrecer por tiempo.
Pos condiciones Se muestra en pantalla el estado de la enfermera
# requerimiento RF005 Nombre Cambiar estado (en turno).

Fuente
Introducción
Precondiciones Haber completado el contador (960) a 0.
Procesos Cambia definición de estado a “en turno” e inicia contador de descuento (480). Se
lista al final de las enfermeras en turno.
Cada que se acepta un servicio, sube una posición en la cola.
Se lista al final de la cola de enfermeras con estado ”en turno”.
# requerimiento RF006 Nombre Cambiar estado (disponible).

Fuente
Introducción
Precondiciones Estar en la segunda posición de la lista “en turno”.
Que la enfermera de la posición 1 cambie estado “disponible a ocupada”
Procesos Se verifica si la enfermera está en la posición 1 de la cola “en turno”. De ser así,
cambia su estado a “disponible”.
# requerimiento RF007 Nombre Cambiar estado (ocupada).

Fuente
Introducción
Precondiciones El doctor debe haber enviado una solicitud de enfermera.
Debe haberse desplegado el mensaje “enfermera solicitada”.
Debe haberse aceptado el servicio.
Procesos Al dar clic en el botón aceptar, cambia estado de enfermera disponible a “ocupada”.
Se ejecuta RF006
# requerimiento RF008 Nombre Solicitar atención (a enfermera).

Fuente
Introducción
Precondiciones Doctor debe haber registrado datos del paciente.
Debe haber dado clic en el botón “solicitar”
Procesos Toma referencia de RF008a. Abre un cuadro de mensaje en el Layout “Enfermera
disponible” informando que se solicita el servicio y los datos del paciente.
Habitación (incluye pabellón) y nombre del paciente. Inicia Counter de descuento =
5 (minutos). Si llega a 0 cambia a RF010
Pos condiciones Si transcurren 5 minutos desde el momento de la solicitud, se repite la acción pero
actualiza a la siguiente enfermera en turno.
Se ejecuta RF006
Excepciones Si los campos están vacío, enviar mensaje de error “No es posible solicitar el
servicio, por favor especifique la habitación del paciente.”
# requerimiento RF008a Nombre Ingresar datos del paciente a atender

Fuente Doctor Selecciona de lista desplegable [combobox] pabellón y habitación.
Introducción
Precondiciones Doctor debe haber registrado datos del paciente.
Debe haber dado clic en el botón “solicitar”
Procesos De arreglo espacio se selecciona habitación.
Algoritmo de búsqueda obtiene datos del paciente.
Pos condiciones Tener los datos de habitación y paciente
# requerimiento RF009 Nombre Aceptar atención (enfermera).

Fuente
Introducción
Precondiciones Estar en pantalla el mensaje de solicitud
Procesos Al dar clic en el botón aceptar, se cierra el mensaje y cambia a RF007
Pos condiciones Solo puede dar clic en el botón aceptar la enfermera que tenga estado disponible
(ninguna otra).
Se ejecuta RF006.
# requerimiento RF010 Nombre Terminar atención (enfermera).

Fuente
Introducción
Precondiciones Enfermera debe tener estado de “ocupada”.
Procesos Bicola (sistema circular) en turno, cambia estado al dar clic en terminar
Pos condiciones Al terminar, cambia al final de la cola de enfermeras con estado “en turno”.
# requerimiento RF011 Nombre Mostrar Tiempo (funcional).

Fuente
Introducción
Precondiciones
Procesos Muestra estado del counter de estado “en turno” (480) si está en turno o counter de
estado “en descanso” (960), si esta fuera del sistema circular.
Pos condiciones
# requerimiento RF012 Nombre Consultar enfermera (Doctor).

Fuente
Introducción
Precondiciones
Procesos
Pos condiciones
# requerimiento RF013 Nombre Asignar en minutos los tiempos

Fuente
Introducción
Precondiciones
Procesos Contador x - - desde turnoIn = 480 hasta 0 y contador y - - desde turnoOut = 960
hasta 0
Pos condiciones
# requerimiento RNF01 Nombre Mostrar Tiempo (No funcional).

Fuente Clases Calendar y GregorianCalendar
Introducción Reloj visual en un espacio de la ventana principal
Precondiciones
Procesos Muestra el reloj en la ventana principal a un tamaño grande, simulando el reloj de
pared
Pos condiciones
La siguiente es una propuesta de interfaz gráfica de usuario del sistema en una versión preliminar.
Ventana Principal, desde donde se gestiona todo el sistema.

Ventana para la selección del Registro, cuando el doctor se vincula a la función Registrar.
Formulario de Registro de Pacientes. La variación con los formularios de enfermera y doctor, radican
únicamente en los datos que se capturan.
A continuación presentamos una propuesta preliminar del diagrama de Clases (esta estructura junto a los
demás elementos expuestos en esta entrega, serán mejorados respecto a la forma de presentar la
información mediante el estándar UML, ya que la segunda entrega define los casos de uso, junto a otros
aspectos que modifican estas clases, ya que cada vez el trabajo será más específico).

Ent1ProyAulEstDat2015 Up

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

Ent1ProyAulEstDat2015 Up

Cargado por

Copyright:

Formatos disponibles

Propuesta de Software “Downtime”

Entrega 1 del Proyecto de Aula: Estructuras de Datos

2.2. Objetivos específicos

Cada enfermera se identifica por su nombre y tiene asignado en minutos la duración

Los turnos de las enfermeras están organizados de manera circular.

Al principio no había ni tantos pacientes, ni médicos, ni enfermeras y se llevaba a

La enfermera de turno, sabe si está ocupada con un paciente.

Los doctores requieren saber cuántas enfermeras hay en el hospicio,

Los doctores y las enfermeras requieren saber si ha cambiado el estado de

retorna la enfermera de turno si no está ocupada, o null en caso contrario; la

Vamos a considerar los siguientes aspectos:

Al principio no había ni tantos pacientes, ni médicos, ni enfermeras y se llevaba a

5. APLICABILIDAD DE LOS TEMAS DEL MÓDULO.

Registro Estados Solicitud Consultas

Gestión de Registro Asignacion

Control de Enfermera Solicitud

Actor Enfermera # 001

Actor Doctor # 002

Actor Esquema de Turno # 003

Los siguientes son los requisitos específicos del sistema:

# requerimiento RF002 Nombre Registrar Persona (Enfermera).

# requerimiento RF003 Nombre Registrar Persona (Paciente).

# requerimiento RF004 Nombre Cambiar estado (en descanso).

# requerimiento RF005 Nombre Cambiar estado (en turno).

# requerimiento RF006 Nombre Cambiar estado (disponible).

# requerimiento RF007 Nombre Cambiar estado (ocupada).

# requerimiento RF008 Nombre Solicitar atención (a enfermera).

# requerimiento RF008a Nombre Ingresar datos del paciente a atender

# requerimiento RF009 Nombre Aceptar atención (enfermera).

# requerimiento RF010 Nombre Terminar atención (enfermera).

# requerimiento RF011 Nombre Mostrar Tiempo (funcional).

# requerimiento RF012 Nombre Consultar enfermera (Doctor).

# requerimiento RF013 Nombre Asignar en minutos los tiempos

# requerimiento RNF01 Nombre Mostrar Tiempo (No funcional).

Ventana Principal, desde donde se gestiona todo el sistema.

También podría gustarte