Tema 2

EL ANÁLISIS DEL PROBLEMA
F.J. Zarazaga Soria, J. Nogueras Iso, M.A. Latre Abadía
Ingeniería del Software I
Versión 2.1 (febrero 2.002), revisión 2.1.6 (febrero 2.006), revisión 2.1.7 (febrero 2.010)
Departamento de Informática e Ingeniería en Sistemas

“El análisis de sistemas es frustrante; está repleto de
relaciones interpersonales complejas, indefinidas y
difíciles. En una palabra, es fascinante. Una vez que
uno se vuelve adicto, los viejos placeres fáciles de la
construcción de sistemas ya nunca vuelven a
satisfacerle.”
Tom DeMarco. Structured Analysis and
Systems Specification. Englewood Cliffs, N.J.:
Prentice Hall, 1979, página 6.
2

Índice
1. Determinar requisitos
2. Las labores de análisis
3

EL ANÁLISIS DEL PROBLEMA
1. Determinar requisitos
F.J. Zarazaga Soria, J. Nogueras Iso, M.A. Latre Abadía
Ingeniería del Software I
Departamento de Informática e Ingeniería en Sistemas

Determinar requisitos. Índice
1.1. El problema de la comunicación.
1.2. ¿Qué es determinar requisitos?
1.2.1. Búsqueda de requisitos.
1.2.2. Clasificación de los requisitos.
1.2.3. Especificación de los requisitos.
1.3. Algunas técnicas utilizables.
1.3.1. Tablas de requisitos.
1.3.2. Entrevistas.
1.3.3. Reuniones.
1.3.4. Cuestionarios.
1.3.5. Árboles de decisión.
1.3.6. Tablas de decisión.
1.3.7. Los Casos de Uso.
5

Ejercicio de Comunicación (I)
6

Ejercicio de Comunicación (II)
7

Ejercicio de Comunicación (III)
8

Necesitamos vichy de cuadros o de un color vivo, de 30 cm
de ancho y largura y media del área que vamos a cubrir.
Haremos una jareta en la parte de arriba de 5 cm de ancho,
dejando 3 cm para la patilla y 2 para la goma. Una vez este
pasada, hacer una presilla e cada extremo para poder
colgarlo. En la parte de abajo se efectúa un dobladillo
estrecho y se remata con puntos de escapulario o de tripa.
Para finalizar, se hacen unos círculos de bodoques y otros
de ojetes alternando uno de cada. En el centro de éstos se
hace un grupo de rococos.
9

1.1. La Torre de Babel (I)
“The mythical man-month” , F.P.Brooks (1995)
10

La Torre de Babel (II)
Según el Génesis, fue el segundo gran proyecto de
ingeniería, después del Arca de Noé. Pero fue el
primer fiasco.
El proyecto contaba con todos los factores
necesarios para el éxito:
Una clara misión.
Mano de obra.
Materiales.
Suficiente tiempo.
Adecuada tecnología.
Entonces, ¿qué fallo?
La comunicación y, consecuentemente, la organización.
11

1.2. ¿Qué es determinar requisitos?
Los requisitos no son el objetivo del proyecto.
Determinar requisitos consiste en estudiar un sistema para conocer
como trabaja y donde es necesario efectuar mejoras.
Un requisito es una característica que debe incluirse en el nuevo
sistema. Esta puede ser la inclusión de determinada forma para
capturar o procesar datos, producir información, controlar una
actividad de la empresa o brindar soporte a los directivos. El
cumplimiento de dichos requisitos será una condición básica para la
aceptación final del sistema por parte de los usuarios.
Los analistas de sistemas no trabajan como directivos o empleados de
los departamentos de usuarios, no tiene los mismos conocimientos,
hechos y detalles que los usuarios y directivos de estas áreas. Por lo
tanto el primer paso del analista es comprender la situación.
12

1.2.1. Líneas de investigación del analista (I)
Los analistas se deben reunir con:
los responsables del área que se está tratando que
aportan una visión global del sistema
con los usuarios finales que aportan el detalle de la zona
que controlan
Los analistas estructuran su investigación en base
a 4 preguntas:
¿Cuál es el proceso básico que se está estudiando?
¿Qué datos utiliza o produce este proceso?
¿Qué frecuencia y volumen del proceso existe?
¿Qué controles utiliza para su realización?
13

Líneas de investigación del analista (II)
¿Cuál es el proceso básico que se está estudiando?
¿Cuál es la finalidad de esta actividad en la empresa?
¿Qué pasos se siguen para llevarla a cabo?
¿Donde se realizan estos pasos?
¿Quienes los realizan?
¿Cuánto tiempo tardan en efectuarlos?
¿Con cuanta frecuencia lo hacen?
¿Quienes emplean la información resultante?
¿Qué datos utiliza o produce este proceso?
Este paso consiste en detectar qué datos se utilizan para
llevar a cabo cada actividad.
14

Líneas de investigación del analista (III)
¿Qué frecuencia y volumen de proceso existe?
Los analistas deben investigar con cuanta frecuencia se repite
una actividad. Esto cambia mucho dependiendo de la actividad
ya que por ejemplo el pago de la nómina se repite
mensualmente o semanalmente pero el pago de impuestos es
anualmente.
La manera más fácil de obtener esta información es identificar
el objetivo de la actividad, es decir, cuál es la causa de la
actividad.
El volumen de los procesos puede aumentar el tiempo de
realización de las actividades, es decir la cantidad total de
pasos que puede constar una actividad puede generar
problemas aún ocurriendo con poca frecuencia.
15

Líneas de investigación del analista (IV)
¿Qué controles utiliza para su realización?
¿Quién se encarga de comparar lo realizado con los estándares?
¿Cómo se detectan los errores?
¿Cómo se corrigen los errores?
16

Fuentes de Información
Alguna de las fuentes más comunes son:.
Usuarios del sistema
Formularios y documentos
Programas
Manual de procedimiento
Informes
17

Catálogo de requisitos
Con la información recogida se empezará a elaborar un
Catálogo de Requisitos a satisfacer por el nuevo sistema.
Los requisitos identificados en la realización de estas
actividades han de ser definidos de modo que:
Sean cuantificables y medibles.
Sean lo suficientemente detallados para reducir cualquier
tipo de ambigüedad y permitir validar si el nuevo sistema
satisface las necesidades de los usuarios.
Se minimice la duplicación de los diferentes productos
obtenidos en la Fase de Análisis.
18

1.2.2. Clasificación de los requisitos (I)
Requisitos funcionales. Describen lo que debe
hacer el sistema en cuanto a:
Funciones de actualización de datos.
Funciones de consulta.
Informes proporcionados.
Datos manejados.
Interacción con otros sistemas.
19

Clasificación de los requisitos (II)
Requisitos no funcionales. Describen las facilidades que
debe proporcionar el sistema en cuanto a:
Rendimiento. Volumen y tamaño de datos.
Frecuencia de tratamiento.
Requisitos de seguridad:
Control de accesos
Procedimientos de copias de respaldo y recuperación
Integridad de la información
Requisitos especiales de comunicaciones.
Requisitos organizacionales
Directrices técnicas y de gestión.
Requisitos generales a cumplir en cuanto a necesidades
futuras de información.
Tendencias de evolución de la empresa.
20

1.2.3. Especificación de los requisitos (I)
Principios de una especificación
Separar funcionalidad de implementación.
Ser modelo de conocimiento, no de diseño o
implementación.
Ser tolerante a la completitud.
Ser ampliable.
Ser operativa.
21

Especificación de los requisitos (II)
Criterios que rigen una especificación
Huir de las conectivas persuasivas:
por lo tanto, obviamente, ciertamente, ...
Indagar qué hay detrás de los términos imprecisos:
alguno, a veces, a menudo, la mayoría, ...
Averiguar qué hay en una lista sin fin:
etc., y así sucesivamente, otros, ...
No admitir suposiciones de conocimiento.
Cuidado con verbos de interpretación múltiple:
manejar, rechazar, procesar, ignorar, ...
Si se especifican cálculos, probar al menos con dos
ejemplos.
Buscar certezas y exigir pruebas:
siempre, cada, todos, ...
22

Los problemas para expresar la lógica (I)
No solo pero no obstante, y/ o a menos que...
¿Cuál es la diferencia entre las siguientes 5 oraciones?
Sumar A a B a menos que A sea menor que B, en cuyo caso
restar A de B
Sumar A a B. Sin embargo, si A es menor que B, la respuesta
es la diferencia de A y B.
Sumar A a B, pero restar A de B cuando A es menor que B.
El total se encuentra sumando B a A. A pesar de la
expresión previa, en caso que B sea mayor que A el
resultado será la diferencia entre B y A.
El total es la suma de A y B. Sólo cuando A sea menor que B
deberá usarse la diferencia como total.
No existe diferencia lógica
SI A es menor que B ENTONCES restar A de B
SINO sumar A a B
23

Los problemas para expresar la lógica (II)
Mayor que, menor que
Más de 20 unidades, 5% de descuento
¿inclusive? ¿no inclusive?
Buscar sustituciones por: mayor que, mayor o igual que,
menor que, menor o igual que
Ambigüedad y/ o
Los clientes que nos compran más de $ 10.000 por año y
tienen una buena historia de pagos o que han
comerciado con nosotros por más de 20 años deberán
recibir trato preferencial.
(más de $ 10.000 por año) y (buena historia de pagos
o más de 20 años)
(más de $ 10.000 por año y buena historia de pagos)
o (más de 20 años)
24

1.3. Algunas técnicas utilizables
Tablas de requisitos.
Entrevistas.
Reuniones.
Cuestionarios.
Árboles de decisión.
Tablas de decisión.
Casos de uso.
25

1.3.1. Tablas de requisitos
Es una técnica muy sencilla de representación de los
requisitos mediante una simple tabla.
Un requisito se identifica mediante un código cuya
estructura responde a un estándar fijado por la
organización.
Junto al código se procede a describir el requisito.
En el resto de la aplicación permite indicar de una
manera muy sencilla que parte del desarrollo se
encarga de satisfacer un requisito concreto.
Código Descripción
26

Ejemplo de tabla de requisitos
Filmoteca Española
Código Descripción
RF-1 Las entradas/salidas de material fílmico se realizarán a través de la puerta que existe en el Archivo
de películas, donde se reflejará dicha recepción o salida mediante recibo.
RF-2 Se ha de mantener históricos de los movimientos externos realizados por los materiales.
RF-3 Se ha de obtener información de materiales que habiendo salido en un movimiento externo no han
sido devueltos.
RF-4 Los materiales que hayan formado parte de Filmoteca no se borran, solo se dan de baja (lógica).
RF-5 Mantener histórico sobre los derechos de las películas.
RF-6 Mantener históricos sobre los estados físicos de los materiales.
RF-7 Las pantallas de consultas de materiales han de ser lo más compactas posibles (incluso varios
materiales en una sola pantalla).
RF-8 No todo el material que entre en el almacén provisional pasa a formar parte del Archivo definitivo.
RNF-1 El sistema debe funcionar en una red de área local.
RNF-2 El sistema debe contar con un control de usuarios.
27

1.3.2. Entrevistas
Este es el método más corriente para recoger
información del usuario.
Es un proceso continuo utilizado por el analista
para construir gradualmente un modelo del
sistema y para obtener conocimientos sobre los
problemas del sistema.
Factores de éxito de una entrevista:
Elegir a la persona a entrevistar. Buscar la persona clave.
Encontrar el camino correcto para dirigir la entrevista.
Buscar la cooperación necesaria.
28

Planificación de una entrevista
El plan de entrevista
El usuario a entrevistar
La secuencia en la que será entrevistado
El plan de entrevista para cada usuario
El objetivo de una entrevista es maximizar el volumen de
información relevante a obtener del entrevistado.
La preparación de las entrevistas es esencial.
Se debe tener una idea de lo que se pretende conseguir con la
entrevista y formular preguntas directas para obtener es
información.
Si el entrevistado no puede contrastar, se le preguntará dónde
se podría obtener dicha información.
No se debe esperar obtener toda la información necesaria de
un usuario en el curso de una entrevista
29

Contenidos de una entrevista
Las entrevistas deben efectuarse de forma organizada y
amistosa.
El entrevistador siempre será cortés y respetará la oposición
y necesidades del usuario.
Es importante no imponer soluciones a los usuarios, sino el
papel de asesor.
La jerga informática no se debe utilizar para impresionar al
usuario, los entrevistadores deben explicar las limitaciones
del ordenador en términos cotidianos y describir al usuario
cómo le puede ayudar en su trabajo.
Los entrevistadores deberán asegurarse de obtener toda la
información necesaria de la entrevista. Para eso ayuda poner
en conocimiento del usuario la información que se pretende
obtener con la entrevista.
30

Pasos a seguir en una entrevista
Se establecen los procedimientos de entrevistas (duración y
lo que se piensa obtener, así como conseguir permiso para
tomar apuntes y notas durante la entrevista).
Normalmente, es una buena idea empezar confirmando la
información obtenida en entrevistas anteriores o en alguna
investigación. Esto sirve para situar al entrevistado y ayuda a
encontrar errores en los datos.
Una vez que se está conforme, se sigue con más detalle
cualquier punto relevante.
La entrevista se terminará resumiendo lo obtenido de ella y
confirmándolo.
Finalmente, es buena idea convenir la fecha para la siguiente
entrevista, si se considera necesaria.
31

Tipos de preguntas básicas
Preguntas independientes del contexto
¿De quién ha surgido la petición de este proyecto?
¿Quién va a utilizar la solución?
Beneficio de una buena solución.
Preguntas de ámbito
¿Qué problemas resolverá la solución?
Puede describirme el entorno en el que se utilizará la solución.
Alguna limitación o aspecto especial de rendimiento.
Preguntas de control
¿Es Ud.. La persona adecuada para responder a estas preguntas?
¿Son oficiales sus respuestas?
¿Estoy haciendo demasiadas preguntas?
¿Hay algo más que deba preguntarle?
32

1.3.3. Reuniones
Se pueden ver como una prolongación de las
entrevistas en las que se involucran varios
entrevistadores y varios entrevistados.
Suelen utilizarse en fases muy tempranas de la
determinación de requisitos.
Es una técnica aplicable en muchas fases del
proceso de desarrollo del software:
Análisis del sistema a construir.
Diseño del sistema a construir.
Seguimiento del proceso de desarrollo.
...
33

Estrategias para facilitar las reuniones
Reunión en un lugar neutral para técnicos y clientes.
Reglas de preparación y participación (reunión preparatoria
de la reunión).
Agenda formal para cubrir los puntos importantes.
Agenda informal para estimular el br ain-stor ming.
Elección de un moderador.
Herramientas para la discusión:
hojas de trabajo, diagramas, pizarras, etc.
Se debe buscar la creación de confianza mutua y espíritu de
equipo.
34

Decálogo para la celebración de reuniones
1. Pensar si la reunión es necesaria y quién es imprescindible que asista.
2. Enviar convocatoria, lo más documentada posible, fijando la hora de
comienzo y de terminación.
3. Todos los participantes prepararán adecuadamente la reunión antes de
su comienzo.
4. Ser puntuales. Comenzar a la hora prevista.
5. El convocante, o quien él designe, actuará como moderador.
6. Se evitarán todo tipo de interrupciones. Dejarlo advertido previamente.
7. No tratar otros temas que los propios de la reunión.
8. Respetar las intervenciones de los demás. Practicar la escucha activa.
Ser concretos.
9. Terminar a la hora indicada en la convocatoria.
10. Hacer un acta de la reunión, a no ser que se indique lo contrario.
35

Ampliación del decálogo
Las reuniones no deben durar más de dos horas.
Reparto de tareas:
Preparador
Controlador de tiempos
Secretario
Seguir la agenda.
Intentar planificar la celebración de la siguiente
reunión.
Fecha y hora, lugar y tema
36

1.3.4. Cuestionarios (I)
Hay personas que sugieren el cuestionario, en vez de las
entrevistas, para obtener información sobre el sistema.
El cuestionario contiene todas las preguntas que el usuario
debe responder para proporcionar la información que busca
el analista.
El cuestionario se envía al usuario y el analista analiza las
respuestas.
La experiencia sugiere que estos cuestionarios no son
normalmente buenos sustitutos de las entrevistas por el
peligro de ambigüedad de las preguntas.
'describa todos sus trabajos’
'¿cuáles son los componentes principales del sistema?’
37

Cuestionarios (II)
Los cuestionarios, sin embargo, se utilizan cuando se busca
la misma información en usuarios distintos. Es el caso de
información de naturaleza cuantitativa.
Un cuestionario con esta pregunta es fácil enviarlo a todos los
vendedores de la organización.
Los cuestionarios se utilizan también como complemento de
otras técnicas.
Se usan para recoger datos numéricos u obtener opiniones
relativamente simples de un número de personas.
No son efectivos para búsquedas detalladas ni para
identificar problemas o soluciones del sistema.
38

1.3.5. Árboles de decisión
Sirven para organizar la información recopilada con respecto
a la toma de decisiones y no haya malas interpretaciones.
Características:
La raíz del árbol es donde comienza la secuencia de decisión, la
rama a seguir depende de las condiciones y de la decisión que
debe tomarse. La parte final es la acción.
raíz
condición
condición
condición
condición
condición
condición
acción
acción
acción
acción
El problema de los árboles de decisión es el gran número de
ramas que puede tener un sistema complejo.
39

Ejemplo de árbol de decisión
Autorización de descuento por pronto pago:
Si el cliente paga dentro de los 10 primeros días y el
importe es superior a 10.000€, se le aplica un 3% de dto.
Si el cliente paga dentro de los 10 primeros días y el
importe es entre 5.000€ y 10.000€, se le aplica un 2% de
dto.
En el resto de los casos no se autorizan dtos.
raíz
dentro de
10 días
más de
10 días
>10.000€
5.000€-10.000€

1.3.6. Tablas de decisión
Una tabla de decisión se divide en dos partes (condiciones,acciones), y
está formada por 4 secciones.
La parte de condiciones establece todas las condiciones que se
aplican a los datos.
Las acciones son las acciones distintas que se pueden tomar
dependiendo de las condiciones.
Una tabla de decisión se construye usando columnas, de forma que
cada columna corresponda a una combinación de condiciones.
Las acciones tomadas para las condiciones de las columnas se dan
por una cruz en las columnas. Si la línea de acción tiene una cruz,
entonces se toma esa acción si se da el conjunto de condiciones de
la columna. A esto se le llama r eglas de decisión.
Identificación de
condiciones
Identificación de
acciones
Entrada de condiciones (cada columna representa una
combinación de condiciones)
Entrada de acciones (cada cruz representa una regla
de decisión)
41

Ejemplo de tabla de decisión
Pago de los servicios médicos.
La atención sanitaria en un hospital es de carácter obligatorio,
sin preocupar la financiación de la asistencia. Si el paciente
dispone de seguridad social, su asistencia estará exenta de
pago, sino es así pero dispone de un seguro médico sólo hará
frente al pago de la consulta . Sólo en el caso de no disponer el
paciente ni de seguridad social, ni de seguro médico pagará
todos los servicios.
42

1.3.7. Presentación de los Casos de Uso (I)
Los casos de uso (Use Cases) es una técnica para determinar
las necesidades de un sistema.
Ha sido desarrollada por Ivar Jacobson y se han integrado en
la notación UML que lleva camino de convertirse en el
estándar de notación para metodologías OO.
Se están utilizando como guías para todo el proceso de
desarrollo del software.
Bibliografía sobre Casos de Uso
I. Jacobson. Object-Oriented Software Engineering. A Use Case
Driven Approach. Addison-Wesley Publishing Company, 1992.
G.Booch, J.Rumbaugh, I.Jacobson. El lenguaje unificado de
modelado UML. Addison Wesley, 1999.
43

Presentación de los Casos de Uso (II)
Los casos de uso describen bajo la forma de acciones y
reacciones el comportamiento de un sistema desde el punto de
vista de un usuario; permiten definir los límites del sistema y las
relaciones entre el sistema y el entorno.
Es la imagen de la funcionalidad del sistema, desencadenada en
respuesta a la estimulación de un actor externo
Reubican la expresión de las necesidades sobre los usuarios
La estructuración del método se efectúa respecto a las
interacciones de una sola categoría de usuarios a la vez
Usuario B.
Usuario D.
Conjunto de
Necesidades
Usuario C.
Usuario A.
44

Presentación de los Casos de Uso (III)
Los usuarios deben estructurar y articular sus deseos:
Definir de manera precisa como interactuar con el sistema
Precisar qué informaciones quieren intercambiar
Describir qué debe hacerse para obtener el resultado deseado
Necesidad de un formalismo para los casos de uso accesible
para los diferentes usuarios sin necesidad de una formación
particular
Modelo de casos de uso:
Sistema
S i s t e m a
Actores
Casos de uso
A c t o r A
C a s o d e U s o X
C a s o d e u s o Y
A c t o r B
45

Actores
Un actor representa el papel interpretado por una persona o
una cosa que interactúa con el sistema
Se representan en forma de pequeños personajes que
desencadenan los casos de uso
Los actor es se reclutan entre los usuarios directos del sistema,
los responsables de su configuración y mantenimiento, así
como los otros sistemas que interactúan con el sistema en
cuestión
La determinación de los mismos precisa los límites del sistema
de manera progresiva. Sirve de base contractual para limitar lo
que debe hacerse, lo que forma parte del sistema a desarrollar
y lo que no forma parte de él
46

Categorías de Actores
Cuatro grandes categorías de actores :
Actores Principales:
Personas que utilizan las funciones principales del sistema.
Ejemplo : Los clientes de un dispensador de billetes
Actores Secundarios:
Personas que realizan actividades administrativas o de
mantenimiento. Ejemplo : Persona que recoge la caja del
dispensador
Actores Material Externo:
Dispositivos materiales imprescindibles que forman parte del
ámbito de la aplicación y que deben ser utilizados. Ejemplo :
Impresora. (no el ordenador en sí mismo)
Actores Otros Sistemas:
Sistemas con los que el sistema a desarrollar debe interactuar.
Ejemplo: Sistema grupo bancario que gestiona el parque de
dispensadores
47

Casos de Uso
Los casos de uso son abstracciones del dialogo entre los
actores y el sistema
Se representan por medio de un óvalo identificado por un
nombre
Describen interacciones potenciales, llamadas escenar ios, sin
entrar en detalles concretos
Un caso de uso agrupa una familia de escenarios según un
criterio funcional
Su ámbito de aplicación supera ampliamente la definición de
las necesidades del sistema. Intervienen a lo largo de todo el
ciclo de vida
Es necesario un método para navegar hacia las clases y los
objetos que satisfacen una necesidad y hacia las pruebas que
verifican que el sistema realiza su tarea
48

Relaciones
Tipos de relaciones:
Generalización
Entre Actores
Entre Casos de uso
Extensión entre Casos de
Uso
Inclusión entre Casos de
Uso
Asociación entre un
Actor y un Caso de Uso
C4 siempre ejecuta C2
C1 opcionalmente ejecuta C2
49

Construcción de Casos de Uso
¿Cuales son las tareas de un actor?
¿Qué informaciones debe el actor crear, guardar,
modificar, destruir o simplemente leer?
El actor, ¿deberá informar al sistema de los
cambios externos?
El sistema, ¿deberá informar al actor de las
condiciones internas?
50

Proceso de elaboración de Casos de Uso
Identificar a grandes trazos los casos de uso y
descripción breve de los casos de uso
Profundizar en la comprensión de cada caso de
uso particular, y determinación de los principales
escenarios
Descripción detallada de las etapas estabilizadas,
teniendo en cuenta los escenarios que pasan por
cada etapa
51

Trampas a Evitar
La presencia de un gran número de detalles es un signo
de un escenario más que de un caso de uso
No siempre resulta fácil determinar el nivel de detalle
Un gran número de casos de uso es un signo de falta de
abstracción
Sea cual sea el tamaño del sistema a desarrollar, el número
de casos de uso es relativamente pequeño
No sucede lo mismo con el número de escenarios
Procurar no caer en la tentación de describir demasiado el
comportamiento interno del sistema
Describir los intercambios entre actor y sistema; pero no
llegar a explicar cómo el sistema realiza esos intercambios
Los casos de usos son un medio, no un fin
52

Construye el árbol de decisión
Ejercicio 1:
A un cliente se le dará trato preferencial si cumple una de
estas dos condiciones:
Compran más de 10.000 € por año y tienen una buena historia de pagos
Compran más de 10.000 € por año y han comerciado con nosotros por más
de 20 años
Ejercicio 2:
A un cliente se le dará trato preferencial si cumple una de
estas tres condiciones:
Compran más de 10.000 € por año y tienen una buena historia de pagos
Compran más de 10.000 € por año y han comerciado con nosotros por más
de 20 años
Compran 10.000 € o menos por año y tienen una buena historia de pagos
54

Construye el árbol de decisión
Ejercicio 3:
En una venta de una editorial alibreros el descuento
comercial es del 20 %. En la venta a particulares y bibliotecas,
la editorial concede un 5% de descuento por la compra de 6 o
más libros, 10% para 20 o más libros, y 15% para 50 o más
libros. Los pedidos comerciales de 20 o más libros reciben
un descuento adicional de un 10%.
55

Construye la tabla de decisión
Ejercicio 1:
A un cliente se le dará trato preferencial si cumple una de
estas tres condiciones:
Compran más de 10.000 € por año y tienen una buena historia de pagos
Ejercicio 2:
Compran más de 10.000 € por año y han comerciado con nosotros por más
de 20 años
Compran 10.000 € o menos por año y tienen una buena historia de pagos
Si la cuenta de un cliente se factura un método de tarificación fijo, se establece
una carga mensual mínima para consumos inferiores a 100 Kwh. En los demas
casos se aplica la tarifa A. Sin embargo, si se aplicaun método de tarificación
variable, se aplicará la tarifa A a consumos menores de 100 Kwh. En otro caso, se
facturará de acuerdo a la tarifa B.
56

Construye la tabla de decisión
Ejercicio 3:
Si el importe_total es menor o igual a 10.000 y el %_Descuento es menor del 5%,
entonces el Descuento será cero
Si el importe_total es mayor que 50.000, entonces el Descuento será el
importe_total * %_Descuento + 2.500
En cualquier otro caso el Descuento será el importe_total * %_Descuento
importe_neto = importe_total - Descuento
57

EL ANÁLISIS DEL PROBLEMA
2. Las labores de análisis
F.J. Zarazaga Soria, J. Nogueras Iso, M.A. Latre Abadía
Ingeniería del Software I
Departamento de Informática e Ingeniería en Sistemas

Las labores de análisis. Índice
2.1. El Diagrama de Flujo de Datos.
2.2. El análisis del sistema
2.2.1. Análisis de la situación actual
Construcción del nuevo sistema
2.2.2. Contexto del sistema
2.2.3. Identificación y definición de subsistemas
2.2.4. Especificación de interfaces con otros sistemas
2.2.5. Definición de las interfaces con el usuario
2.2.6. Construcción del esquema lógico de datos
2.2.7. Análisis detallado
2.2.8. Completar especificaciones del sistema
59

2.1. El Diagrama de Flujo de Datos (DFD)
Los diagramas de flujos de datos (DFD), es una técnica de
modelización, que nos muestra un sistema como una red de
procesos conectados entre ellos por flujos y
almacenamientos de datos.
Es un modelo que proporciona el punto de vista funcional de
un sistema.
Utiliza una notación y unas reglas
predeterminadas.
Es la principal herramienta del análisis
estructurado.
60

Ejemplo de DFD
Cajero
Productos
de un ticket
1.1
Crear ticket
1.2
Validar
datos de los
productos
Productos
validados
Ticket base
fecha y hora
Sistema
ticket
Ticket
provisional
1.3
Añadir
productos
al ticket
1.4
Validar
datos del
ticket
2 Ticket
Productos del
ticket validado
1 Producto
1.5
Descontar
unidades del
producto
61

El DFD. Objetivo (I)
Objetivo
Construir un modelo lógico del sistema que facilite la
comprensión del mismo, tanto por parte de los usuarios como
del equipo de desarrollo. Para ello se dividirá el sistema en
distintos niveles de detalle. Esta división permitirá:
Simplificar la complejidad del sistema, representando los
diferentes procesos sencillos de que consta un sistema
complejo.
Repartir el trabajo entre los diferentes miembros del equipo
de desarrollo.
Facilitar el mantenimiento del sistema.
62

El DFD. Objetivo (II)
Los fundamentos de la técnica del DFD son los siguientes:
Representar gráficamente los límites del sistema en estudio.
Mostrar el movimiento de los datos y la transformación de los
mismos a través del sistema.
Diferenciar las restricciones físicas de las lógicas.
63

El DFD. Objetivo (III)
Para conseguir estos objetivos el resultado del
análisis debe ser:
GRAFICO.
LOGICO, nunca referido a entornos físicos.
PRECISO Y BREVE.
COMPRENSIBLE.
DEBIDAMENTE PARTICIONADO.
BIEN DOCUMENTADO.
NUNCA REDUNDANTE.
ESTABLECERA "QUE" FUNCIONES SE DEBEN DESARROLLAR,
SIN IMPLICAR "COMO".
NO AMBIGUO.
64

El DFD. Objetivo (VI)
Como resultado se obtendrá un modelo del
sistema completamente independiente de las
restricciones físicas del entorno, lo que facilitará
su mantenimiento y portabilidad.
En los Diagramas de Flujo de Datos, no se deberán
modelizar:
PROCEDIMIENTOS.
PUNTO DE INICIO Y DE TERMINACION DEL DFD.
CONDICIONES.
TRATAMIENTOS DE ERRORES POCO RELEVANTES.
65

Elementos básicos de un DFD
En cualquier Diagrama de Flujos de Datos,
aparecerán los objetos siguientes:
ENTIDAD EXTERNA.
PROCESO.
ALMACEN DE DATOS.
FLUJO DE DATOS.
La técnica de representación dará lugar a un DFD
en el que se irán detallando los principales
procesos o acciones a desarrollar y que se irán
detallando en mayor medida según se vaya
bajando de nivel (EXPLOSIONANDO) cada uno de
esos procesos.
66

Las entidades externas (I)
Las Entidades Externas representan entes ajenos a
nuestra aplicación, pero que aportan o reciben
información de la misma.
Notación:
Nombre representativo.
Un número identificativo de la entidad.
En el caso de que dentro de un DFD aparezca repetido la
misma entidad externa, se puede representar de la
siguiente forma:
1
Nombre
Simple
1
Nombre
1
Nombre
Métrica V.2.1
1
Nombre
Múltiple
1
Nombre
Yourdon y Gane-Sarson
1
Nombre
67

Las entidades externas (II)
Reglas de construcción:
Representa personas, organizaciones o sistemas que no
pertenecen al sistema.
En el caso de que las entidades externas se comunicasen
entre sí, esto no se contemplaría en el diagrama, por
estar fuera del ámbito de nuestro sistema.
Puede aparecer en los distintos niveles de DFD.
Puede aparecer varias veces en un mismo diagrama, para
evitar entrecruzamientos de líneas.
Suministra información acerca de la conexión del sistema
con el mundo exterior.
68

Las entidades externas. Ejemplos
Notación de entidad
externa utilizada en Métrica
v.2.1
Notación de entidad
externa utilizada en
Yourdon y en Gane-
Sarson
69

Los procesos (I)
Es una actividad que transforma o manipula datos.
Notación:
Nombre del proceso correspondiente. Dependiendo del nivel de
detalle en que nos encontremos dentro de un DFD, el nombre del
proceso simbolizará bien el sistema concreto (nivel sistema), bien el
subsistema de que se trate (nivel subsistema), o bien acciones
concretas y detalladas en niveles inferiores.
Un número identificativo del proceso. Este número permitirá
además indicar el nivel del DFD en que nos encontramos
(descomposición por niveles). Es importante hacer énfasis en que
este número no indica secuencia de realización del proceso, dado
que los DFD no representan una secuencialidad en el tratamiento
de los datos.
1 AREA
NOMBRE
Métrica v.2.1
1
NOMBRE
Yourdon
1
NOMBRE
Gane-Sarson
70

Los procesos (II)
Reglas de construcción:
Cuando un Flujo de datos entra en un proceso sufre una
transformación. Un proceso no es ni origen ni final de los
datos, sólo lugar de transformación de los mismos. Por ello,
cualquier flujo de datos que entre en un proceso ha de
transformarse.
Un proceso puede transformar un dato en varios.
Es necesario un proceso como intermediario entre una
Entidad Externa y un Almacén de Datos.
A
B
MAL
1
Proceso 1
C
B
2
Proceso 2
3
Proceso 3
D
E
BIEN
B
A
1
Proceso 1
2
Proceso 2
C
E
3
Proceso 3
D
71

Almacén de datos (I)
Un almacén de datos representa un depósito de
información dentro del sistema.
Notación:
Nombre del almacén de datos.
Un número identificativo del mismo 1 Nombre
En el caso de que dentro de un DFD aparezca repetido el
mismo almacén de datos, se puede representar de la
siguiente forma:
1 Nombre
1 Nombre
Simple
1 Nombre
1 Nombre
Múltiple
72

Almacén de datos (II)
Diferentes utilidades que representan los
almacenes de datos.
Almacenamiento permanente de datos (ALMACENES
PRINCIPALES).
Almacenamiento transitorio de los datos antes de ser
usados por un proceso.
73

Almacén de datos (III)
Reglas de construcción:
Representa la información en reposo.
No puede crear, destruir ni transformar datos.
No puede estar comunicado directamente con otro
Almacén o Entidad Externa.
El flujo de datos (Entrada o Salida) no lleva nombre
cuando incide sobre su contenido completo.
El almacén de datos aparecerá por vez primera en aquel
nivel en que sea accedido por dos o más procesos y en
modo lectura y/ o escritura.
74

Los flujos de datos
Los Flujos de Datos establecen la comunicación entre
procesos, almacenes y entidades externas, y llevan
información necesaria para esos objetos.
Reglas de construcción:
El concepto de flujo de datos es similar al de una "tubería" a
través de la cual fluye una información de estructura conocida.
Los datos no pueden ser creados ni
destruidos por un flujo de datos.
Sirve para conectar el resto de los
componentes del DFD.
No es un activador de procesos.
Cuando un proceso almacena datos, la
flecha de flujo de datos se indica en la
dirección del almacén de datos y a la
inversa si es el proceso el que lee datos
en el almacén.
75

Conexiones permitidas en un DFD
Entidad
Proceso
Almacén de datos
Entidad Proceso Almacén de datos
x √ x
√ √ √
x √ x
76

Descomposición por niveles (I)
Los Diagramas de Flujo de Datos han de representar el Sistema
de la forma más clara posible, por ello se basarán en el
principio de descomposición o explosión en distintos niveles
de detalle.
La descomposición por niveles permite analizar el sistema
desde el ámbito general al detalle, pasando por sucesivos
niveles intermedios (filosofía de arriba a abajo o "top-down").
La utilización de esta técnica implica la descomposición o
explosión de cada proceso en otro DFD.
El sistema deberá contener:
Un diagrama de contexto (primer nivel).
Varios DFD en niveles intermedios.
Varios DFD en el último nivel de detalle.
77

Descomposición por niveles (II)
Procedimiento:
Representar el Diagrama de Contexto.
Representar el DFD de primer nivel,
indicando los distintos subsistemas en
que se descompone nuestro sistema.
Descomponer cada uno de los procesos
que aparecen en el DFD hasta llegar a
un nivel suficiente de detalle.
Si es necesario, reagrupar y reorganizar
los distintos subsistemas que se han
identificado inicialmente,
Repetir el proceso de descomposición
hasta llegar a un nivel suficiente de
detalle.
78

Descomposición por niveles (III)
La identificación de las áreas funcionales o subsistemas se
hará atendiendo, entre otros, a los siguientes criterios:
Funciones organizativas o administrativas propias del sistema a
desarrollar y específicas de la problemática de la Unidad.
Homogeneidad de las funciones realizadas por los procesos
pertenecientes a un área funcional o subsistema.
Localización geográfica de los procesos.
Procesos que actualicen los mismos almacenes de datos se
colocarán en el mismo subsistema o área funcional.
El objetivo último será conseguir que las comunicaciones o
enlaces entre distintos subsistemas o áreas funcionales sean lo
más reducidas y homogéneas posibles
79

Ejemplo de descomposición por niveles
80

Especificación de procesos (I)
Objetivo:
Describir la lógica de los procesos.
Deberán definirse en más detalle sólo las funciones o
procesos primitivos, es decir, aquellos que no se han
descompuesto más.
No se detallarán funciones que resulten obvias.
Cada especificación de proceso debe describir cómo se
logra transformar el flujo de datos que llega en los flujos
que salen.
Cada especificación de proceso debe describir las normas
que gobiernan la transformación, no el método de implantar
esas normas.
81

Especificación de procesos (II)
Se han de incluir en la descripción de los procesos
de último nivel los siguientes aspectos:
Modo de acceso de los procesos a las entidades de datos
del sistema.
Tipo de tratamiento (interactivo o por lotes).
Información sobre la frecuencia de ejecución.
Características del proceso:
Actualización de datos del sistema.
Consultas e informes.
Realización de algoritmos específicos y descripción de
los mismos.
82

Especificación de procesos. Técnicas (I)
Técnicas para la descripción de procesos:
Tablas de decisión.
Árboles de decisión.
Narrativa tradicional.
Lenguaje estructurado.
83

Especificación de procesos. Técnicas (II)
Narrativa tradicional
Tiene la debilidad inherente del lenguaje natural como herramienta
para especificar:
Imprecisa.
Redundante.
Llena de implicaciones y connotaciones.
Ejemplo:
“Para aplicar el descuento, el cliente debe tener una cifra de
compra de más de 3.000.000 de pesetas/ año y un buen historial
de pagos o haber sido cliente más de 5 años".
¿Cuál es el significado de la anterior descripción narrativa?
o ¿3.000.000 pts. y un buen historial?
o ¿3.000.000 pts y 5 años?
o ¿Basta con los 5 años?
o ¿Qué quiere decir un buen historial de pagos?
84

Especificación de procesos. Técnicas (III)
Lenguaje estructurado
Debe ser comprensible para el informático y el usuario.
Utiliza una sintaxis limitada sin llegar a ser tan rígida como una
codificación.
Las descripciones deben ser precisas y concisas, evitando la
retórica del lenguaje.
Utilizar verbos precisos sin ambigüedad, evitando, por ejemplo:
HACER, TRATAR, PROCESAR, CONTROLAR.
Los nombres utilizados deben estar definidos en el diccionario de
datos.
Los adjetivos utilizados deben ser auto-explicativos. Por ejemplo:
VALIDO, ERRONEO.
No deben utilizarse los adjetivos, adverbios y verbos que expresan
relatividad. Por ejemplo: Incrementar, reducir, escaso, suficiente,
etc.
Hay que indicar de forma inequívoca el objeto sobre el que debe
aplicarse la acción.
85

Especificación de procesos. Técnicas (IV)
Sintaxis del lenguaje estructurado:
Sentencias declarativas simples.
Construcciones de decisión.
Construcciones de repetición.
Combinaciones de ambas.
Las acciones escritas de esta forma son fáciles de leer y
de entender.
Ejemplo:
• SECUENCIA:
ACCION 1
ACCION 2
ACCION 3
ACCION 4
ACCION 5
• DECISION:
• METODO DE LOS CASOS
PARA CADA TRANSACCION
SI (CONDICION), SELECCIONAR:
ENTONCES
CASO 1: ACCION 1
ACCION 1
CASO 2: ACCION 2
ACCION 2
CASO 3: ACCION 3
CASO CONTRARIO,
ACCION 3
86

Especificación de procesos. Técnicas (V)
Consejos prácticos para utilizar el lenguaje estructurado:
La excesiva anidación de sentencias condicionales (si/ no)
complica la comprensión de las especificaciones.
Utilizar el método de los casos cuando la lógica del proceso sea
compleja, por existir diversidad de opciones.
Evitar sentencias del tipo "HACER HASTA" o "HACER MIENTRAS".
Emplear expresiones positivas, evitando sentencias del tipo: "Si
la transacción no es errónea..."
Evitar expresiones matemáticas complejas.
No debe estar referido al entorno físico y por tanto, no se
diferencian los ficheros convencionales de las Bases de Datos.
No se representa la clave de acceso a ese almacén sino sólo la
operación que se realiza (lectura, escritura, actualización)
87

Pautas para dibujar los DFDs (I)
Identificar las entidades externas involucradas.
Identificar las entradas y salidas de información previstas en el
normal funcionamiento. Marcar las que únicamente estén
relacionadas con condiciones de error y excepciones.
Identificar las consultas y los pedidos de información que
podrían surgir.
Diferenciar información dada al sistema frente a r equer ida por el
sistema.
Tomar la entidad externa que parece la principal proveedora de
información:
dibujar los flujos que de ella surjan
los procesos que son lógicamente necesarios
y los almacenamientos de datos que se requieran.
Repetir con las demás entidades sin preocuparse de numerar
procesos.
88

Pautas para dibujar los DFDs (II)
Dibujar el primer borrador a mano alzada concentrándose
en incluirlo todo, excepto errores, excepciones y decisiones.
Aceptar que se van a necesitar tres borradores del DFD de
nivel superior.
Cuando se tenga listo el primer borrador, revisar que se ha
incluido la lista de entradas.
Recordar que cada dato que describe algún hecho exterior
del mundo real debe ser creado y mantenido.
Confeccionar un segundo borrador más claro minimizando
cruces de flujos de datos:
Primero duplique entidades externas
Luego duplique almacenamientos de datos
89

Pautas para dibujar los DFDs (III)
Si se tiene un representante simpático del usuario,
revisar con él el segundo borrador:
explicar que solamente es un borrador
tomar nota de aclaraciones y cambios
Producir una explosión de nivel inferior de cada
proceso del segundo borrador.
Si merece la pena la inversión, buscar un dibujante
experto que copie el diagrama de nivel superior
“en bonito” sobre un A0.
90

Técnicas de mejora y prueba de DFD (I)
Pruebas de corrección
En la descomposición de un proceso puede que se nos
olvide alguno de los Flujos de Datos (FD) del nivel
superior, o que el FD de ese nivel superior se
descomponga pero se incluya algún flujo que no debería
aparecer o nos falte alguno.
Faltan flujos de datos requeridos por un proceso.
Flujos de datos de ningún valor para el proceso.
Faltan procesos.
Incoherencia entre niveles.
91

Técnicas de mejora y prueba de DFD (II)
Ejemplo
En el proceso 3 del DFD de nivel
superior entran los flujos de
datos m y n y sale el flujo de
datos t.
En el DFD resultado de la
descomposición del proceso 3,
representado en la parte inferior
de la figura, el flujo de datos de
entrada es n y los flujos de datos
de salida son t y s.
Aunque el número de flujos de datos netos de
entrada y salida no coincida de un nivel a otro, el
contenido de dichos flujos sí lo haga.
92

Técnicas de mejora y prueba de DFD (III)
Pruebas de utilidad
Son más de sentido común que de un estudio exhaustivo sobre
los DFD.
Comprobar si el diagrama es legible.
Analizar la complejidad de la interfaz.
Comprobar que los nombres asignados ayudan a
comprender sin ambigüedad el DFD.
93

Reglas de consistencia de un DFD
Existen reglas para asegurar la consistencia del DFD con otros
modelos de sistemas (el diagrama de entidad-relación, diagrama
transición de estados, diccionario de datos, especificación de
procesos, etc.).
Evite sumideros infinitos, procesos que tienen entradas pero no salidas.
Evite burbujas de generación espontánea, procesos que tienen salidas
sin tener entradas. Situación normalmente incorrecta.
Cuidado con flujos y procesos no etiquetados, ya que puede esconder
errores importantes.
Tener cuidado con los almacenes de “sólo lectura” o “sólo escritura”, ya
que todo almacenamiento debe tener un flujo entrante y uno saliente,
es decir, la información se almacena y se consume.
Las entidades externas no pueden acceder directamente a ningún
almacenamiento. Siempre debe mediar un proceso que haga de
intermediario y extraiga o inserte la información pertinente.
94

Diccionario de datos (I)
El diccionario de datos es una lista organizada de
todos los datos pertenecientes al sistema, con una
serie de definiciones precisas y rigurosas para que
tanto el analista como el usuario comprendan
entradas, salidas, elementos de los
almacenamientos y cálculos intermedios.
En el diccionario de datos incluimos almacenes de
datos, flujos de datos, estructuras de datos,
elementos de datos y en algunos casos el modelo
E-R.
95

Diccionario de datos (II)
El diccionario de datos (DD) describe los datos que se manejan en
el sistema desde cuatro puntos de vista:
Describe el significado de los flujos de datos y los almacenes que
muestran los DFD's.
Describe la composición de la estructura de datos que se mueven a los
largo de los flujos.
Describe la composición de la estructura de datos en los almacenes.
Describe los detalles de las relaciones entre almacenes que aparecen
en un diagrama entidad-relación.
El analista necesita del DD por cuatro razones:
Para manejar los detalles ya que es imposible recordarlo todo.
Para tener una visión común de todos los elementos del sistema.
Para documentar las características del sistema.
Localizar errores en el sistema.
96

Contenido de un DD
Definiciones lógicas de datos:
Elemento de Dato (Atributos de la Entidad).
Menor unidad de un dato que tiene significado para los
analistas.
o Ej: Número de factura
Estructura de Dato.
Grupo de datos elementales o de otras estructuras de
dato que en su conjunto describen un componente del
sistema.
o Ej: Factura
Flujos de Datos.
Almacenes de datos.
Definiciones lógicas de procesos.
Definiciones lógicas de entidades externas.
97

Propuesta de notación de un DD (I)
Notación del elemento dato: Cada uno está identificado con un
nombre, una descripción, un alias, una longitud, restricciones de
valores.
Nombre de los datos
Deben ser significativos. Por ejemplo: Fecha-factura.
No deben ser mayor de 30 caracteres, ni contener espacios en blanco.
Descripción de los datos
Debe ser comprensible para el lector y pensando que quien lo lea no
sabe nada con respecto al sistema.
Alias
El mismo dato recibe varios nombres, según quien haga uso del dato.
Ejemplo para factura: documento de pago o nota de pago ...
No son alias los siguientes casos: factura autorizada, factura
verificada.
Longitud: indica la cantidad de espacio necesario para cada dato.
Restricciones en los valores de los datos (unidades, rangos, etc.).
98

Propuesta de notación de un DD (II)
Descripción de las estructuras de datos: Se
construyen sobre cuatro relaciones de
componentes (datos o estructuras):
Relación secuencial: Componentes (datos o estructuras)
que siempre se incluyen en una estructura de datos en
particular.
Relación de selección: Alternativas para datos o
estructuras incluidas en una estructura de datos.
Relación de iteración: Define la repetición de un
componente cero o más veces.
Relación opcional: Es un caso especial de la iteración, es
decir, una o ninguna iteración.
99

Propuesta de notación de un DD (III)
Descripción de los flujos de datos: Representamos los flujos
de datos siempre y cuando el flujo no sea un único atributo.
Están compuestos por una o más estructuras
Nombre del flujo de datos:
Nombres que sean significativos. Por ejemplo: factura.
Fuente: indica cual es el proceso (número) fuente de la
información.
Destino: indica cual es el proceso (número) destino de la
información.
Definición: explica el contenido del flujo de datos.
Contenido: describe cuales son las estructuras de datos
incluidas.
100

Propuesta de notación de un DD (IV)
Descripción de los almacenamientos de datos:
Nombre de almacenamiento de datos.
Nombres que significativos. Ejemplo: histórico facturas.
Flujos de entrada: indica cuales son los flujos que
alimentan el almacenamiento de datos.
Flujos de salida: indica cuales son los flujos que extraen
información del almacenamiento de datos.
Definición: describe el contenido del almacenamiento de
datos.
Contenido: especifica el contenido del almacenamiento.
101

Propuesta de notación de un DD (V)
Descripción de los procesos:
Nombre de proceso
Entradas: indica cuales son los procesos,
almacenamientos de datos que ejercen de fuente de
datos.
Flujos de salida: indica cuales los procesos,
almacenamientos de datos que ejercen de destino de
datos.
Definición: indica la misión del proceso.
Descripción: describe el proceso según alguna de las
técnicas vistas.
102

Propuesta de notación de un DD (VI)
Descripción de las entidades externas:
Nombre de entidad externa
Flujos de datos asociados: indica cuales son los flujos
(entrada / salida) asociados.
Definición: indica quienes son la entidad.
Volumen: Número de componentes de la entidad.
103

Implementación de un DD
Repositorio de datos
Herramientas automáticas integradas dentro de un
entorno CASE.
Diccionario de datos de SGBD o SO modernos
Dan soporte automático para definiciones de datos,
validar su consistencia, producir algunos informes.
Procesador de textos convencional
Totalmente manual
104

Ejemplo de DD (I)
Dato elemental
Nombre : Estado_Civil
Descripción : Código de una letra para indicar el estado civil de
cada empleado.
Long y tipo : 1 carácter alfabético.
Sinónimos :
ESTADO (Personal)
CIVIL (Nóminas)
Valores :
S Soltero D Divorciado
C Casado S Separado
V Viudo O Otros
105

Ejemplo de DD (II)
Estructura de dato
Nombre : Empleado
Descripción : Datos necesarios de un empleado.
Componentes :
Nombre_empleado +
Num_empleado +
Datos_personales =
Fecha_nacimiento +
Estado_Civil +
Num_hijos [ 0 - ] +
(Num _ tfno)
Dirección =
Calle +
Número +
(Población) +
Codigo_Postal +
Provincia
106

Ejemplo de DD (III)
Flujo de datos
Nombre : Pago _ aceptado
Ref : 11.1 - 11.2.
Fuente : 11.1 Aceptar pago
Destino : 11.2 Validar pago
Descripción : Pago recibido y sellado pero no validado.
Estruct de datos :
Cheque +
Recibo _ Caja +
(Letra _ Pago) +
Metodo _ pago
Volumen : 5000 por día
Comentarios : La letra de pago esta omitida en el 10 % de los
casos.
107

Ejemplo de DD (IV)
Almacenamiento de datos
Nombre : Historia _Pedidos
Ref : P4.
Flujo de Entrada : 9 - D4 Pedido
Flujo de Salida :
D4 - 10 Detalles pedido
D4 - 11 Detalle ventas
D4 - 9 Demanda anterior
Descripción : Todos los pedidos aceptados en los últimos 6
meses.
Contenido : Pedido =
Id_pedido +
Detalle_cliente +
Detalle_libro
108

Ejemplo de DD (V)
Entidad Externa :
Nombre : Proveedores.
Ref : p.
Definición : Proveedores actuales de la empresa.
Flujos de Datos :
7 - p Pedidos.
p - 3 Albarán.
p - 11 Facturas.
Volumen : Actualmente 25. Se espera llegar a 40.
109

2.2. El análisis del sistema
Análisis de la situación actual
Construcción del nuevo sistema
Contexto del sistema
Identificación y definición de subsistemas
Especificación de interfaces con otros sistemas
Definición de las interfaces con el usuario
Construcción del esquema lógico de datos
Análisis detallado
Completar especificaciones del sistema
110

2.2.1. Modelo físico del sistema actual (I)
Representar gráficamente, sin notación formal, el
funcionamiento del sistema actual desde un punto de vista
físico
funciones que realiza
flujo de información entre las mismas
las entradas, salidas y almacenamiento de la información
comunicaciones con otras unidades de la organización
Analizar los flujos de información del sistema y detectar los
nuevos requisitos de información.
Identificar los objetivos de la unidad que pretende cubrir el
sistema requerido.
Identificar los archivos principales y documentos que serán
fuente de información.
111

Modelo físico del sistema actual (II)
Revisar los aspectos funcionales del sistema existente (manual o
automático)
Principales entradas de datos.
Principales funciones que se ejecutan.
Las principales salidas.
Evaluar la información producida por el sistema actual.
Satisfacción de las expectativas del usuario.
Información requerida por el usuario pero no producida por el sistema.
Departamentos donde se producen demoras en el flujo de la
información.
Otras deficiencias
operativa complicada o engorrosa, informes superfluos o de escasa
utilización, tiempos de respuesta excesivamente altos,
funcionamiento deficiente de algunas operaciones, etc.
La revisión del sistema existente facilitará la identificación de
nuevos requisitos que deberá satisfacer el sistema a desarrollar.
112

Modelo lógico actual
Representa gráficamente el modelo lógico, tanto
para datos como para procesos, del sistema actual
grandes procesos o subsistemas que lo componen y flujos
de información entre ellos
entidades de datos, u objetos sobre los que el sistema
guarda información y las interrelaciones entre ellas.
El objetivo es conocer el funcionamiento del sistema
actual, de un modo conceptual
Los modelos obtenidos en la realización de esta
actividad permitirán identificar nuevos requisitos del
sistema mediante la comparación con el sistema
actual
113

Modelo lógico actual de procesos (I)
Construir un Modelo Lógico actual de procesos:
Eliminar todas las referencias al entorno físico.
Tratar de mostrar qué funciones se hacen, y no cómo se
hacen.
Determinar las grandes funciones del sistema en estudio,
que serán contempladas posteriormente como
subsistemas.
Identificar las entradas y las salidas como flujos de
información de cada uno de los subsistemas.
Definir las principales entidades de datos que estos
subsistemas utilizan.
Descomponer cada subsistema, si se considera
necesario.
114

Modelo lógico actual de procesos (II)
Técnica a utilizar: DFD en el que se muestren
Las actividades o procesos que realiza el sistema.
Los flujos de datos entre los mismos.
Los almacenes de datos (lugares donde se guardan los
datos utilizados por las funciones de consulta y
actualización).
Las entidades externas con que el sistema se comunica.
Identificar nuevos requisitos para el sistema, a
partir del modelo lógico actual de procesos.
115

Modelo lógico actual de datos
Identificar las entidades u objetos sobre los que se
desea almacenar información, y sus principales
atributos.
Estudiar los recursos utilizados por el mismo y los
documentos, pantallas e informes actualmente
existentes.
Definir las asociaciones entre las entidades identificadas
anteriormente.
Diseñar el Modelo Lógico de Datos.
Técnica a utilizar: Diagramas Entidad-Relación
Identificar nuevos requisitos para el sistema, a partir
del modelo lógico actual de datos.
116

Construcción del nuevo sistema
En esta actividad se realizará una descomposición
funcional del sistema en sus Subsistemas
Principales.
Se hará una primera descripción de QUE es lo que
el sistema debe hacer en vez de COMO lo va a
hacer.
Una vez identificados los subsistemas principales,
se describirán en detalle, definiendo sus
componentes, con el fin de obtener una
especificación lo más completa posible.
117

2.2.2. Contexto del sistema (I)
Definir las relaciones del sistema con sus usuarios,
con otras aplicaciones, siempre indicando estas
relaciones como flujos de datos de entrada o
salida.
Identificar qué usuarios o aplicaciones delimitan el
sistema, en el sentido de que tienen entradas y salidas
con él mismo.
Identificar la información que aportan o reciben del
Sistema.
Eliminar todas las referencias al entorno físico.
118

Ejemplo de diagrama de contexto (I)
119

Ejemplo de diagrama de contexto (II)
Pulsador Local ArD
Pulsador Remoto ArD
Pulsador Local ArG
Pulsador Remoto ArG
Interruptor Enable Ar
Pulsador Consola TOC
Pulsador Consola Store
Pulsador Consola Grand Air
Serial Line interface
pr_ard_o
pr_ard_f
pl_arg_o
pl_arg_f
pr_arg_o
pr_arg_f
i_conda
pc_toc_o
pc_toc_f
pc_sto_o
pc_sto_f
pl_ard_o
pl_ard_f
pc_gra_o
pc_gra_f
serial_pom
serial_toc_f
serial_sto_f
serial_ard_f
serial_arg_f
serial_diag
Diagrama de contexto
BGTOC
m_drv_o
m_drv_f
m_pas_o
m_pas_f
m_toc_o
m_toc_f
f_toc_end
a_toc_niv
m_sto_o
m_sto_f
a_sto_niv
m_ard_o
m_ard_f
a_ard_niv
m_arg_o
m_arg_f
a_arg_niv
a_bat_niv
Motor Driver
Motor Passenger
Motor TOC
Detector End TOC
Current Sensor TOC
Motor Store
Current Sensor Store
Motor ArD
Current Sensor ArD
Motor ArG
Current Sensor ArG
Voltage Sensor Bat
120

2.2.3. Identif. y def. de subsistemas (I)
Dividir el sistema en diferentes subsistemas para
su desarrollo posterior.
Homogeneidad de las funciones que realizan los
diferentes subsistemas.
Datos que manejan, con el fin de disminuir la
comunicación entre los subsistemas.
Localización geográfica de los subsistemas.
Factores de seguridad.
Respuesta a eventos externos (solicitud de información,
demanda de servicios, etc.).
Fechas de entrega de alguna parte del sistema.
121

Identif. y def. de subsistemas (II)
Representar gráficamente, mediante un DFD, los diferentes
subsistemas identificados en el paso anterior y las
comunicaciones entre ellos.
Se identifican, representan y describen las entradas y salidas y
Flujos de Datos entre los subsistemas.
Se determinan las principales entidades de datos que estos
subsistemas utilizan y se representan como almacenes de datos
en el diagrama.
Descomponer cada subsistema en las funciones de que consta y
representar gráficamente esta descomposición, mediante un
Diagrama de Flujo de Datos (DFD)
122

Identif. y def. de subsistemas (III)
Para identificar las nuevas funciones de los subsistemas, es
necesario considerar:
El detalle de los nuevos subsistemas identificados.
Funciones necesarias para soportar los requisitos del Catálogo.
Funciones de mantenimiento de los nuevos datos en el modelo
de datos del nuevo sistema.
123

Identif. y def. de subsistemas (IV)
Describir las distintas funciones identificadas en los DFD.
Descomponer de cada una de las funciones identificadas en otro
DFD que muestre el detalle las diferentes subfunciones de que
consta esta función.
Describir cada una de las subfunciones identificadas.
Modo de acceso a las entidades de datos del sistema.
Características de la subfunción:
Actualización de datos.
Consultas e informes.
Realización de algoritmos específicos y descripción de los
mismos.
Tipo de tratamiento (en lotes o interactivo).
Información sobre la frecuencia de ejecución.
124

Identif. y def. de subsistemas (V)
En el caso de que la descripción de alguna de
estas subfunciones sea demasiado extensa, puede
ser conveniente proceder a la descomposición de
la misma en otro DFD que muestre el detalle de
los diferentes procesos elementales que describen
dicha subfunción.
Determinar los diferentes eventos del sistema (sucesos
que activan procesos o funciones que actualizan datos
del sistema).
Refinar los modelo obtenidos
125

Identif. y def. de subsistemas (VI)
Ejemplo DFD de nivel de subsistema
Cajero
Productos de un
ticket
fecha y hora
Sistema
ticket
1
Gestión
ventas
1 Producto
2 Ticket
2
Gestión
productos
Reponedor
Datos Nuevo producto
Datos Borrar producto
Datos Actualizar
producto
126

2.2.4. Interfaces con otros sistemas
Determinar para cada uno de los diferentes subsistemas
identificados, las interfaces con otros sistemas o
subsistemas, especificando:
Datos transferidos.
Modo, Medio y Frecuencia de la interfaz.
Suceso que origina y desencadena la interfaz.
Deberá recogerse información sobre el formato de los datos
que van a comunicarse.
Identificar las interfaces (Diagrama de Contexto).
Especificar los datos a ser transferidos/ recibidos.
Indicar los aspectos operativos de la interfaz (en lotes,
interactiva, medio, frecuencia).
Identificar los sucesos o eventos que desencadenan la
realización de la interfaz.
127

Descripción de procesos manuales
Nos interesan aquellos procesos manuales
relacionados con un proceso interactivo (p. ej.
introducción de datos en pantalla) frente a
aquellos procesos manuales sin relación directa
con procesos automáticos (p. ej. revisión de un
listado).
Para procesos manuales relacionados con
procesos automáticos especificar:
Datos de entrada a introducir por pantalla.
Datos de salida mostrados en pantalla.
Descripción sencilla del diálogo y manejo de la pantalla.
128

2.2.5. Interfaces con el usuario
Comprenden menús, formatos de pantallas, diálogos,
formatos de informes y formularios de entrada.
Prevalecen los requisitos de usuario sobre las definiciones
técnicas.
La participación activa de los usuarios del nuevo sistema es
imprescindible.
Es necesario conocer aspectos relacionados con las
validaciones de campos, ediciones, ayudas, secuencias y
navegación entre pantallas, etc.
Uso de prototipos con el propósito de:
reducir el riesgo en la implantación del nuevo sistema.
aumentar la calidad del producto.
incrementar la productividad.
129

Pantallas del sistema (I)
Definir los formatos individuales de las pantallas utilizadas.
Encabezamiento.
Cuerpo principal.
Pie.
Teclas de función.
Teclas de ayuda y líneas de visualización de los mensajes de
ayuda.
Describir de modo detallado los diálogos entre pantallas y el
encadenamiento entre las mismas.
Realizar una representación jerárquica de las pantallas del
Sistema.
Se representarán en los niveles superiores los menús del
sistema, y en los niveles inferiores las pantallas de diálogos,
representativos de funciones o procesos concretos del sistema.
130

Pantallas del sistema (II)
Identificar los menús o diálogos concretos en función de los
grupos de usuarios que los utilicen.
Determinar los diálogos que se consideran críticos para un
funcionamiento correcto del nuevo sistema. Dependerán de:
Tipo de proyecto.
Grado de cambio con respecto al sistema actual.
La complejidad de los trabajos del sistema.
131

Pantallas del sistema (III)
En esta determinación, serán de utilidad los siguientes
criterios:
Frecuencia de uso de esos diálogos.
Acceso a gran número de entidades de datos del sistema.
Gran número de elementos de datos asociados con el diálogo.
Cambio en el modo habitual de trabajo en el sistema actual.
Diálogos comunes a diferentes grupos de usuarios.
Diálogos que contienen opciones complejas de navegación.
132

Pantallas del sistema (IV)
Prototipado de las pantallas del sistema
Determinar el punto de entrada a cada pantalla, y sus
posibilidades de navegación a otras.
Especificar los datos asociados a cada pantalla (longitud,
reglas de validación, mensajes de ayuda, etc.).
Evaluar la consistencia del diseño, asegurando que toda
la información necesaria para el usuario está
contemplada en las pantallas y corregirlas en caso
contrario.
Confirmar con el usuario la validez de los diseños de
pantalla realizados.
133

Jerarquía de pantallas (I)
134

Jerarquía de pantallas (II)
Menú principal
Gestión de productos
Ventas
Nuevo producto
Modificar producto
Borrar producto
135

Jerarquía
de pantallas (III)
M e n u
P p a l .
C o n t r o l d e R e d
C o n f i g u r a c i ó n
g e n e r a l
C o n f i g u r a c i ó n
i n f r a e s t r u c t u r a
C o n f i g u r a c i ó n
d e f l o t a s y
t e r m i n a l e s
C o n f i g u r a c i ó n d e
a b o n a d o s
E s t a d í s t i c o s
M a n t e n i m i e n t o
A d m i n i s t r a c i ó n
d e l s i s t e m a
F a c t u r a c i ó n
L l a m a d a s e n c o l a
C o m u n i c a c i o n e s e x i s t e n t e s
L o c a l i z a c i ó n d e u n t e r m i n a l
R e l a c i ó n d e t e r m i n a l e s p o r z o n a
E s t a d o d e l a i n f r a e s t r u c t u r a
M o n i t o r d e a l a r m a s
P a r á m e t r o s g e n e r a l e s
D u r a c i ó n d e l a s c o m u n i c a c i o n e s
A c t u a l i z a c i o n e s s o b r e l a r e d
N o d o C e n t r a l
E s t a c i ó n B a s e d e Z o n a
O p c i o n e s i n f r a e s t r u c t u r a
E d i c i ó n d e f l o t a s
E d i c i ó n d e e q u i p o s
A l t a s y b a j a s d e a b o n a d o s
A s i g . d e f l o t a s y / o e q u i p o s a a b o n a d o s
D u r a c i ó n c o m u n i c a c i o n e s
C o n f i g u r a c i o n e s d i a r i a s
C o n f i g u r a c i ó n f e s t i v i d a d e s m e n s u a l e s
G r u p o s d e
c o m p a r t i c i ó n
S i s t e m a A b i e r t o
C o n f l i c t o s p a r a l a c o m p a r t i c i ó n d e
e n l a c e s d e a u d i o
C o n f l i c t o s p a r a l a c o m p a r t i c i ó n d e
c a n a l e s d e t r á f i c o
G r a d o d e u t i l i z a c i ó n d e l a r e d ( r e p e t i d o r e s , e n l a c e s y a u d i o s )
T r á f i c o g l o b a l
T r á f i c o t o t a l c u r s a d o
T r á f i c o i n d i v i d u a l i z a d o p o r e q u i p o t e r m i n a l
N º d e l l a m a d a s p e r d i d a s y e s t a d í s t i c a d e l a s c a u s a s
N º d e l l a m a d a s i n m e d i a t a s
M e d i a d e d u r a c i ó n d e l l a m a d a s s e g ú n e l t i p o d e l l a m a d a
C á l c u l o d e i n d i c a d o r e s d e c a r g a d e l a r e d
A c c e s o a e l e m e n t o s
L i s t a d o d e i n c i d e n c i a s
A d m i n i s t r a c i ó n d e u s u a r i o s
C o p i a s d e s e g u r i d a d
L i m p i e z a d e l a s B a s e s d e D a t o s
C o n f i g u r a c i ó n f a c t u r a
T a b l a s d e t a r i f i c a c i ó n
L l a m a d a s d e u n a b o n a d o
F a c t u r a r
V i s u a l i z a c i ó n d e f a c t u r a s
C o n t a b i l i d a d g e n e r a l
A c t u a l i z a r d u r a c i o n e s e n l a r e d t r u n k i n g
S i n c r o n i z a c i ó n c o n e l r e l o j d e l a r e d
V o t e n o w
A l t a s y b a j a s d e u s u a r i o s
C a m b i a r P a s s w o r d
L i s t a d o d e u s u a r i o s
H a c e r c o p i a
R e s t a u r a r c o p i a
C o m p a r t i c i ó n d e
e n l a c e d e
s e ñ a l i z a c i ó n
C a n a l d e C o n t r o l y
E n l a c e S e ñ a l i z a c i ó n
c o m p a r t i d o s
136

C o n t r o l d e R e d
C o n f i g u r a c i ó n
d e a b o n a d o s
Jerarquía de
pantallas (IV)
E s t a d o d e l a
i n f r a e s t r u c t u r a
Información de estado
del Nodo Central
L l a m a d a s e n c o l a Llamadas en Cola
C o m u n i c a c i o n e s
e x i s t e n t e s
R e l a c i ó n d e t e r m i n a l e s
p o r z o n a
L o c a l i z a c i ó n d e u n
t e r m i n a l
A l t a s y b a j a s
d e a b o n a d o s
A s i g . d e f l o t a s
y / o e q u i p o s a
a b o n a d o s
Comunicaciones
existentes
Relacion de zonas
Localización de un
terminal
Altas y bajas de
abonados
Selección de Abonado
Información de estado
de la Estación Base
de Zona
Criterios de selección
y ordenación de las
llamadas en curso
Criterios de selección y
ordenación de las
comunicaciones existentes
Relación de terminales
por zona
Asignación de flotas
y/o equipos a
abonados
C o n f i g u r a c i ó n
i n f r a e s t r u c t u r a
N o d o C e n t r a l
E s t a c i ó n B a s e
d e Z o n a
O p c i o n e s
i n f r a e s t r u c t u r a
Configuración Nodo
Central
Configurar EBZ
G r u p o s d e
c o m p a r t i c i ó n
C o n f l i c t o s p a r a l a
c o m p a r t i c i ó n d e
c a n a l e s d e t r á f i c o
C o n f l i c t o s p a r a l a
c o m p a r t i c i ó n d e
e n l a c e s d e a u d i o
S i s t e m a A b i e r t o
C o m p a r t i c i ó n d e
e n l a c e d e
s e ñ a l i z a c i ó n
C a n a l d e C o n t r o l y
E n l a c e S e ñ a l i z a c i ó n
c o m p a r t i d o s
Configurar Conexión
Directa
Configurar
redundancias del NC
Acceso a Centralita
Configurar
redundancias de la
EBZ
Alta Enlace Audio
Alta Repetidor
Configurar EBZ en
modo degradado
Conflictos para la
compartición de
canales de tráfico
Conflictos para la
compartición de
enlaces de audio
Grupos del Sistema
Abierto
Compartición de
enlace de señalización
Canal de Control y Enlace de
Señalización compartidos
Configuración
redundancias en los
Enlaces de Audio
Alta frecuencia
Configurar sistema
abierto
Subgrupo 1 Compartición
Enlace de Señalización
Subgrupo 2 Compartición
Enlace de Señalización
137

A d m i n i s t r a c i ó n
d e l s i s t e m a
F a c t u r a c i ó n
Jerarquía de pantallas (V)
A d m i n i s t r a c i ó n
d e l o s u s u s a r i o s
S
E l a b o r a c i ó n d e
l a s T a b l a s d e
T a r i f i c a c i ó n
M a n t e n i m i e n t o
d e l a s b a s e s
d e d a t o s
T r á f i c o c u r s a d o
p o r u n a b o n a d o
P r e s e n t a c i ó n
d e f a c t u r a s
A l t a s y b a j a s d e
u s u a r i o s
C a m b i a r e l
p a s s w o r d
S
L i s t a d o d e
u s u a r i o s
R e a l i z a c i ó n d e
c o p i a s d e
s e g u r i d a d
L i m p i e z a d e l a
b a s e d e d a t o s
Elaboración de las
Tablas de Tarificación
Tráfico cursado por un
abonado
F a c t u r a d e u n
a b o n a d o
F a c t u r a d e
t o d o s l o s
a b o n a d o s
Criterios de selección y
ordenación del tráfico cursado
por un abonado
Selección del abonado
Factura de todos los
abonados
Altas y bajas de
usuarios
Cambiar el password
Listado de usuarios
Copias de seguridad
Limpieza de la base
de datos
C o n f i g u r a c i ó n
d e f l o t a s y
t e r m i n a l e s
Factura de un
abonado
Criterios de selección y
ordenación de la factura de un
abonado
Criterios de selección y
ordenación del listado de
usuarios
A c c e s o a
G r u p o s
A s i g n a c i ó n
d e f l o t a s
A l t a s y b a j a s
d e t e r m i n a l e s
Grupos de una flota
Asignación de flotas
Terminales de una
flota
Acceso a grupos
Altas de terminales
Redirecciones de un
grupo
Monitores de flota Alta Monitores de flota
Redirección de un
terminal
138

Prototipado simple de pantallas
Producto nuevo
Código del producto:
Descripción:
Precio:
Unidades:
Ticket nuevo
Chequear
Añadir
Salir
Fecha:
Código del producto:
Descripción: Precio:
Ticket:
Total:
Unidades:
Importe:
+
-
Total
Salir
139

Prototipado avanzado de pantallas
140

Informes y formularios
Obtener una definición de los formatos de los
informes generados.
Definir los formularios utilizados (si fuera
necesario).
Verificar que los diseños realizados están de
acuerdo con los estándares de la empresa y
obtener la validación y conformidad de los
usuarios.
141

2.2.6. Construcción del modelo de datos
Modelo Lógico de Datos que recoja:
Todas las entidades de datos de relevancia cuya información va a
ser consultada o procesada de alguna manera en el sistema.
Todas las relaciones existentes entre las entidades de manera que
se pueda acceder a los datos relacionados con cualquiera de las
entidades mediante procesos sencillos.
Las claves de acceso a las entidades, así como los atributos
característicos de las distintas entidades definidas.
Construir Modelo Entidad-Relación y describir las entidades
Normalizar el modelo de datos
142

Actualización de modelo de datos
Cuando un sistema reemplaza a otro ya existente hay que tener
en cuenta:
Definir nuevas entidades de datos (estructuras de datos) para
contemplar las necesidades de información futuras.
Incorporar nuevos atributos de datos a las entidades ya existentes.
Modificar el nombre de las entidades y/ o de los atributos.
Identificar nuevas interrelaciones entre las entidades, teniendo en
cuenta las necesidades de acceso a la información.
Cambiar los atributos clave de las entidades.
Describir completamente las entidades de datos con todos sus
atributos e incorporar información sobre volúmenes estimados,
frecuencia de acceso a las mismas, tiempo medio de
almacenamiento dentro del sistema, etc.
... y las implicaciones que todos estos cambios pueden tener
143

2.2.7. Análisis detallado del nuevo sistema
Modelo del nuevo sistema desde el punto de vista de
los eventos que actúan sobre el mismo, considerando
evento como todo suceso que activa los procesos de
actualización de datos dentro del sistema.
Se estudia la relación entre los procesos y las
entidades de datos
El orden en que se suceden los distintos eventos dentro del
sistema.
La posible existencia de situaciones no usuales, dentro del
tratamiento realizado por el sistema.
La interacción con otros sistemas dentro de la Unidad
144

Catálogo de eventos
Evento: Cualquier suceso que activa a un proceso que actualiza
datos del sistema. Se pueden considerar tres tipos de eventos:
Eventos producidos en el exterior del sistema, por ejemplo,
solicitudes de altas o modificaciones de los datos almacenados en el
sistema. Estos eventos "ponen en marcha" los procesos que realizan
dichas funciones de actualización.
Eventos periódicos: se identifican en los Diagramas de Flujos de
Datos, estudiando aquellos procesos que actualizan los almacenes de
datos, sin un estímulo externo, con una periodicidad temporal.
Por ejemplo:En un sistema donde las entidades a las que no se
haya accedido en cierto tiempo, se archiven, se identificaría el
evento periódico "Archivar entidades".
Eventos reconocidos internamente, por ejemplo, prerrequisitos que el
sistema exige para activar el proceso de actualización.
145

Ejemplo de catálogo de eventos
Filmoteca Española
Evento: FE-ALTA.MATERIAL
Descripción:
o Alta de un nuevo material, que puede producir o no el alta de un
nuevo titular
Evento: FE-CAMBIO.TITULAR
Descripción:
o Notificación del cambio de titular de un material.
Evento: FE-CAMBIO.TITULAR.DERECHO
Descripción:
o Notificación del cambio de titular a un derecho de película. Este
cambio provoca:
Un alta de una ocurrencia en la Entidad FE-DERECHO.
Una modificación de la vigencia en la ocurrencia de la Entidad FE-
DERECHO, que ostentaba el derecho antes del cambio del titular.
146

Diagramas de Estado
Un diagr ama de estados muestra un
comportamiento que especifica la secuencia de
estados por los que pasa el sistema o una entidad
concreta a lo largo de su tiempo de vida, en
respuesta a eventos.
Se emplean para modelar aspectos dinámicos del
sistema :
Muestran el flujo de control de un estado a otro.
Trabajador
pérdida empleo
En Activo
contratación
En el Paro
más de 60 años
más de 60 años
Jubilación
147

Elementos de Modelado
Elementos de modelado de los Diagramas de Estados
:
Estado : condición o situación en la vida de un objeto en la cual
cumple una condición, desarrolla una actividad o bien espera algún
evento.
Transición : relación entre dos estados indicando que una entidad
en el primer estado desarrolla una serie de acciones y entra en el
segundo estado cuando un evento concreto ocurre y se satisfacen
una condiciones específicas.
Evento : especificación de una ocurrencia significativa que tiene
una localización en el tiempo y el espacio, y que desencadena una
transición de estados.
Además de notas y restricciones.
matricular
despegar
En Vuelo
En Tierra
aterrizar
estrellarse
148

Ejemplo: Análisis de cadenas
Parser de cadenas de caracteres con sintaxis :
mensaje :: ‘’ cadena ‘;’
Diagrama de estados :
149

Ejemplo Diagrama de Estados (I)
150

Ejemplo Diagrama de Estados (II)
151

Diagramas de Secuencia
Herramienta muy utilizada en metodologías
orientadas a objeto
Los diagramas de secuencia nos permite mostrar
la secuencia de ejecución de los procesos.
Proceso
1
Proceso
2
152

Redes de Petri
Las redes de Petri son una herramienta que
permite mostrar aspectos de secuenciación de
procesos y de sincronización de los mismos.
Se propone un uso “libre” de las RdP:
promoción de uso como herramienta gráfica,
minimizar aspectos de formalismo
153

Ejemplo de uso
154

Ejemplo de uso
155

2.2.8. Completar la especificación del sistema
En esta actividad se contemplan en detalle los
requisitos no funcionales del sistema, es decir, las
facilidades que debe proporcionar el mismo en
cuanto a:
Seguridad.
Rendimiento.
Frecuencia de tratamiento.
Comunicaciones.
156

Seguridad y Control (I)
Especificar la política de Seguridad y Control para el nuevo
sistema.
Definir exactamente los puntos de control que deben
establecerse para garantizar los requisitos de seguridad
establecidos.
Planificación de la seguridad lógica en tres niveles:
Protección de acceso, establece las posibilidades del acceso a la
información en función de los procesos y sus futuros usuarios.
En casos extremos de necesidad de protección, pueden
emplearse técnicas de encriptación de datos.
Continuidad integral, que indicará los procedimientos
adecuados para asegurar una recuperación de los datos
involucrados en una operación de actualización en caso de
terminación anormal.
Integridad de datos.
157

Seguridad y Control (II)
Determinar los requisitos de seguridad para
almacenamientos de datos, y de otros recursos a
proteger, identificando las causas de peligro. Los
peligros más comunes son:
Modificación.
Destrucción.
Revelación de datos a personas no autorizadas.
Definir requisitos de seguridad para los procesos y
muy principalmente para las transacciones
interactivas.
158

Robustez del sistema
Copias de respaldo, contingencias y recuperación de errores.
Definir las necesidades de copias de seguridad para los
almacenamientos de datos, procesos y transacciones del nuevo
sistema.
Especificar los almacenamientos de datos que deberán entrar en los
procedimientos de copias de respaldo, su periodicidad y condiciones
especiales.
Establecer un plan de contingencias para aquellas situaciones de fallo
crítico del sistema.
Especificar los procedimientos de tratamientos de los errores que se
podrán producir en el nuevo sistema, teniendo especial cuidado en:
Revisar las posibilidades de error y detallar los procedimientos de
recuperación para cada subsistema.
Planificar el contenido de los mensajes de error, teniendo en
cuenta si son fáciles de comprender para el destinatario.
159

Rendimiento del sistema
Especificar requisitos de rendimiento y eficiencia
del nuevo sistema.
Tiempos de respuesta requeridos.
Volúmenes de ocupación dentro del sistema.
Circunstancias especiales de explotación (días o períodos
de alto volumen de transacciones).
Asegurar que la inclusión de las funciones de
seguridad, control, copias de seguridad,
tratamiento de errores, etc., no están limitando el
rendimiento deseado para el sistema.
160

V&V de la especificación del sistema
Asegurar la coherencia y exactitud de los modelos
obtenidos.
Garantizar que los modelos obtenidos satisfacen los
requisitos recogidos en el Catálogo de Requisitos del
Sistema.
Esto se debería hacer mediante una revisión con el Grupo de
Calidad y con los usuarios.
Comprobar con el Grupo de Calidad, que la documentación
elaborada como producto final de este módulo sigue los
estándares establecidos. Se harán las correspondientes
modificaciones con el objetivo de ajustarse al máximo a
estos estándares.
Una vez revisadas las especificaciones, y corregidos sus
posibles defectos, deberá haber una aprobación formal de
las mismas por parte del Comité de Dirección. No se
continuará con la Fase siguiente hasta que el equipo del
proyecto no cuente con esta aprobación.
161

162

Ejercicio de Análisis: “Gestión de aula informática” (I)
Un aula informática de una escuela universitaria tiene la
siguiente política de reservas:
Los alumnos pueden reservar un máximo de 4 horas a la
semana.
Las reservas pueden realizarse hasta el día anterior al
uso.
Cuando un alumno hace una reserva A, se le entrega un
justificante de la misma. El formato del justificante es el
siguiente.
Reserva Aula Informática
Número de Expediente: 54.321
Nombre: Alicia Kensington Carroll
Equipo: 014
Día reservado: 28-06-93
Hora reservada: 16:00
163

Ejercicio de Análisis: “Gestión de aula informática” (II)
Cuando se abre el Aula hay un listado de las reservas
realizadas sobre cada equipo, de modo que la gente puede
usar los equipos no reservados. El formato del listado de
reservas es el siguiente:
Reservas del aula informática
001
014
014
…
Equipo
10:00
10:00
16:00
…
Hora
Día: 28-06-93
Peter Pan
María Montesa
Alicia Pérez
El horario del aula es de 10:00 a 18:00 todos los días lectivos
y las reservas comienzan siempre a una hora en punto
…
Alumno
164

Ejercicio de análisis: gestión de un aparcamiento
público
Un aparcamiento público admite tant o a clientes que cogen el ticket en la entrada, como a abonados que
cuentan con una tarjeta que los identifica. Para ello, el aparcamiento cuenta con dos barreras, una a la entrada
y otra a la salida, conectadas al ordenador de gestión. La barrera de entrada dispone de un lector de tarjeta de
abonados y un expendedor de tickets, mientras que la barrera de salida cuenta también con un lector de
tarjetas y con un lector de tickets.
Cuando un usuario llega a la barrera de entrada y retira el ticket de ent rada, el emisor de tickets envía un
mensaje al ordenador indicando el código del ticket y la fecha y hora de ret irada del mismo, y abre
automáticamente la barrera. El código del ticket es un número secuencial y cíclico que va generando el emisor
entre 0 y 99.999. Si el usuario es abonado, entonces el lector de tarjeta de abonado envía un mensaje al
ordenador de gestión con el número de abonado y se queda esperando a recibir confirmación de que puede
abrir la barrera. El número de abonado está entre el 1 y el 999.
Un usuario no abonado debe pasar por caja antes de poder salir. El cajero dispone de un lector inteligente de
tickets. Al int roducir un ticket en el lector, éste solicita al ordenador al que está conectado que le remita la
fecha y hora de entrada con el fin de poder calcular el importe. Una vez que el operario valida el pago de este
importe, el lector envía un mensaje al ordenador para que apunte el ticket como disponible para salir. Cuando
el usuario va a salir con el coche, introduce el ticket pagado en el lector que se encuentra en la barrera de
salida. Este envía un mensaje al ordenador para que confirme que el ticket ha sido pagado y que autoriza la
salida.
Cuando un usuario abonado desea sacar su coche del aparcamiento, introduce su tarjeta en el lector de la
barrera de salida. Este lector envía un mensaje al ordenador confirmando que puede dejar pasar al abonado.
Pese a ser un único dispositivo físico, cada una de las barreras está integrada por t res dispositivos lógicos (la
barrera en sí, el lector de tarjet a de abonado y el expendedor o el lector de tickets) que obedecen y se
comunican por separado con el ordenador de gestión.
Un abonado debe haber pasado su tarjeta por el lect or de salida antes de poder volver a utilizarla en el de
entrada.
Un ticket que no ha sido pagado no debe permitir abrir la barrera de salida.
Se debe atender las peticiones de apertura de barrera, tanto de entrada como de salida, en menos de tres
segundos.Del abonado se debe guardar información referente a su nombre, su dirección y su número de
teléfono.
165