You are on page 1of 6

Evaluación Alternativa A.D.A.

Ejercicio 1

Directora:
Beatriz López

Componentes:
Juan Jesús Pérez Luna
Juan Diego del Moral
Rubén Rodríguez Ronso
Fernando Nieto Villanova
Antonio García Ruiz
Alejandro Rojas López
Eugenio Gómez Martínez
David Sánchez
Miguel Cuenca Tirado
Juan Luís Blanco Guzmán
Roberto Franco Arce
Inmaculada Arenas Baldrich

INGENIERÍA INFORMÁTICA
GRUPO 2
10 NOVIEMBRE 2008
ÍNDICE

Tabla de Contenido
1. Especificación del problema...................................................................3
2. Análisis de requisitos..............................................................................
2.1 Catálogo de tipos..........................................................................
2.2 Especificación de las Pre/Postcondicionales................................
3. Pruebas del programa.............................................................................
3.1 Plan de pruebas.............................................................................
3.2 Pruebas de caja negra / funcionales..............................................
3.3 Pruebas de caja blanca..................................................................
4. Diseño del sistema..................................................................................
4.1 Estrategias para facilitar el diseño................................................
4.1.1 Para mejorar la eficiencia...................................................
4.1.2 Para mejorar la corrección..................................................
4.1.3 Para distribuir el código entre los métodos........................
4.2 Pseudocódigo................................................................................
4.3 Resultados de las pruebas.............................................................
4.4 Cálculo de la eficiencia temporal y espacial................................
4.5 Análisis de los resultados obtenidos.............................................
4.5.1 Resultados óptimos.............................................................
4.5.2 Obtención en todos los casos de respuestas.......................
5. FAQ................................................................................................
6. Referencias.....................................................................................
6.1 Bibliográficas........................................................................
6.2 Electrónicas...........................................................................
1. Especificación del problema

Es necesario reducir las listas de espera de un centro hospitalario, asignando a los N


quirófanos (Lista Quirófanos) que en él se encuentran, de la forma más equilibrada las
distintas intervenciones quirúrgicas (Lista intervención).
Cada quirófano tiene asignadas E especialidades (E>>N). Disponemos de una lista L,
compuesta por listas de las distintas especialidades donde se encuentran los pacientes
esperando una asignación.

Diseñar un algoritmo voraz que sea capaz de asignar de la forma más optimizada posible el
reparto de los pacientes entre los quirófanos disponibles, dependiendo de la especialidad,
de forma que el tiempo de espera de los pacientes sea el menor posible.

El algoritmo se ejecutará cada semana de forma que los pacientes conozcan el día y la hora
de la intervención. Los pacientes no deberán esperar más de 30dias una intervención y en
el caso que así sea, se indicará la imposibilidad de cumplirlo.

2. Análisis de Requisitos

2.1 Catálogo de tipos


Aquí especificamos los tipos de datos que hemos utilizado en cada una de las clases
necesarias para poder realizar el algoritmo voraz. En primer lugar especificamos los tipos
de las clases auxiliares y a continuación las clases usadas oara los datos de entrada, de
salida y para el algoritmo voraz que vamos a usar.

Clase Paciente Clase Quirofano


Nombre: String listEspec lista de especialidades
horasNecesarias: hora horasDiaArr Array[7] hora
fechaIngreso: fecha horasDia hora
especialidad: String horaInicio hora
fClase lleno boolean
fClase
Clase AlgoritmoQuirofanos Clase Solucion
lp: lista<paciente>
listaEspera, lparray: pacien Paciente
lista<lista<paciente>> quirof Quirofano
listaQuirofano: lista<quirofano> Diaop fecha
sol: lista<intervencion> Horaop hora
k, posicionLista: entero fClase
hComienzo, hCita: hora
aux, pac: paciete
qui: quirofano
salir, encontrado: logico
diaInicioAlgoritmo: fecha
fClase

2.2Especificación de las Pre/Postcondicionales

Precondiciones del problema


∀ i:1..E Y ∀ j:1.. llp.get(i).get(j).Size()
llp.get(i).get(j).getFechaDeIngreso() < llp.get(i).get(j+1).getFechaDeIngreso()
(de esta forma nos aseguramos que los pacientes están ordenador por fecha de ingreso).

∀ i:1..E Y ∀ j:1.. llp.get(i).get(j).Size()


llp.get(i).get(j).getEspecialidad() = llp.get(i).get(j+1).Especialidad()
(Cada paciente que se encuentra en la lista de cada especialidad tiene el mismo atributo de
especialidad).

E>N
(El número de especialidades es mayor al número de quirófanos)
Todos los pacientes tienen que llevar menos de 30 dias en la lista de espera

Postcondiciones del problema


∀ i:1..E Y ∀ j:1.. llp.get(i).get(j).Size()
llp.get(i).get(j).getFechaDeOperacion() - llp.get(i).get(j).getFechaDeIngreso() < 30 dias
3. Pruebas del programa

Para poder comprobar que el algoritmo que hemos desarrollado funciona


correctamente, de tal forma que obtengamos una solución que satisfaga los requisitos
especificados, es necesario realizar una serie de pruebas para poder encontrar errores
(en el caso que los hubiera). De esta forma, podemos encontrar e identificar datos
erróneos o que simplemente son distintos a los que estábamos esperando. Es realmente
necesario someter al algoritmo a una serie de pruebas y comprobaciones (Testing),
poniéndonos en una gran multitud de casos posibles. No obstante, aunque realicemos
infinidad de pruebas con resultado positivo, sólo lograríamos probar que en los casos
especificados el algoritmo funciona correctamente, pero no demostraríamos que el
algoritmo no contenga errores o que funcione en el resto de los casos dónde no hemos
probado nada.

3.1 Plan de Pruebas

Nuestro plan de pruebas lo vamos a realizar sobre toda la clase AlgoritmoQuirofanos


Plan de Pruebas
Es un conjunto de pruebas, donde cada prueba, debe indicar qué propiedades del
algoritmo se desean probar y especificar la prueba.
1.Difinimos grupos de pruebas (macro-objetivos): Dividimos el espacio de datos
de entrada en clases de equivalencia que provoquen comportamientos diferentes del
algoritmo.
2. Definimos casos de pruebas (micro-objetivos): Seleccionamos un dato
“normal” de cada clase de equivalencia y probamos con todos los datos “frontera”
(valores extremos de la clase de equivalencia). Se realiza toda la combinatoria posible
entre los diferentes tipos de datos de la entrada.
3. Comprobamos teniendo en cuenta las pruebas anteriormente realizadas, el
grado de cobertura del código.
4. Para los segmentos y ramas no cubiertas definimos casos de pruebas de caja
blanca.
Informar tan pronto como sea posible de los resultados obtenidos en las pruebas.

3.2 Pruebas de caja negra / funcionales


En estas pruebas comprobaremos que se cumplen los requisitos. En nuestro algoritmo
voraz, lass entradas son

3.3 Pruebas de caja blanca

Texto ejemplo: En nuestro caso al ser considerado todos los segmentos y ramas en las
anteriores pruebas (100% de cobertura) no hace falta generar nuevos casos de test. Si
no se dispone del código se podrán generar después de desarrollarlo.

You might also like