Clase 11 Requerimientos para los Datos y para los reportescs.uns.edu.ar/materias/rs/downloads/CLASES...

Clase 11 Requerimientos para los Datos y para los reportes

Sonia Rueda

Req del Negocio

Req no Funcionales

Req del Usuario

Req Funcionales

Req para los datos

Captura Análisis Especificación Validación

Los primeros encuentros con los clientes se enfocan a capturar los requerimientos de alto nivel.

Sin embargo, ya en esas primeras sesiones de trabajo aparecen referencias, más o menos explícitas, a los datos.

Requerimientos del Negocio

Requerimientos No Funcionales

Una buena práctica es registrar estas referencias para retomarlas más adelante, sin perder en ese momento el objetivo de concentrarse en los objetivos del negocio, la visión del producto y el alcance del proyecto.

Documento de Visión y Alcance



El diagrama de conceptos y el diagrama de contexto, especificados en el Documento de Visión y Alcance y acordados con el cliente en las primeras iteraciones, serán más adelante un buen punto de partida para comenzar a concentrarse en los requerimientos para los datos.




Requerimientos tácitos

Enfoque centrado en el usuario



Requerimientos del Usuario







Modelo de CU




Modelo de CU


Requerimientos para los Datos

Requerimientos Funcionales





Modelo de CU





SRS




Modelo de CU





SRS

Modelo de Casos de Uso


Es fundamental lograr la consistencia entre las distintas especificaciones que conforman un modelo.

Un modelo de datos especifica los datos que van a ser almacenados por el sistema en forma más o menos permanente y sus relaciones.

En muchas aplicaciones el modelo de datos tiene un rol protagónico, la mayoría de los requerimientos funcionales se refieren a como procesar y consultar datos.

En otras aplicaciones él rol principal lo tienen los requerimientos funcionales, aunque hay datos de entrada y de salida, las necesidades del usuario están más bien vinculadas al comportamiento.

Un modelo de datos puede especificarse con

diferentes niveles de abstracción.

El primer nivel queda definido durante el

desarrollo de requerimientos.

El modelo se refina luego durante la etapa de

diseño.

Modelo Lógico

Modelo Conceptual

Modelo Físico

Desarrollo de Requerimientos

Diseño

Implementación

Un modelo lógico de datos es una representación

abstracta, no considera restricciones de

implementación.

Un mismo problema puede modelarse de

diferentes maneras y utilizando diferentes

técnicas.

Los modelos lógicos no van a variar demasiado

dependiendo de la técnica.

El Diagrama de Conceptos, el Diagrama de

Contexto y el Diagrama de Casos de Uso

brindan información útil para comenzar a

modelar los datos.

Los sistemas con los cuales el nuevo producto va a interactuar probablemente también brinden información relevante respecto a los datos.

En algunos casos esta situación puede representar una limitación, ya que el nuevo sistema queda condicionado por restricciones de los sistemas con los que interactúa.

La construcción del modelo de datos comenzará representando la estructura estática de los datos compartidos con otros sistemas.

Las sesiones de captura basadas en el análisis

de documentos son una valiosa oportunidad

para identificar requerimientos de datos.

En particular son fuente de requerimientos:

Formularios y Reportes

Capturas de pantallas

Manuales del usuario

Registrar Devolución

Socio

Registrar Nuevo Socio

Actualizar Catálogo

Bibliotecario

Comprobar Estado

Consultar

Suspender Socio

Registrar Préstamo

Renovar Préstamo

Iniciar Sesión

Notificar retrasos

Dar de Baja Socio

Director

Taller Mecánico

Asignar

Vehículos

Completar

Formulario

del servicio

Capataz

Mecánico

Ingresar

Vehículo

Iniciar

Formulario

Autorizar

Salida

Registrar

Vehículo

Cajero

Registrar

Factura

Notificar

OK

Registrar

Cta Cte

Consultar

Gestión de Servicios del

Taller Mecánico

Sistema de Cobro

Capataz

Mecánico

Cajero

Con la visión del producto propuesta en este ejemplo, no es relevante representar al capataz o al cajero, salvo que se requiera identificación. Sí hay que representar a los mecánicos porque se les asignan vehículos. También surgirán datos de la interacción con el Sistema de Cobros.

Nuestro conocimiento del dominio en general va a ser una ayuda pero en ocasiones puede resultar un obstáculo.

Es fundamental considerar la necesidad del usuario.

Un modelo de datos adecuado para modelar el estado actual, por ejemplo, puede dejar de serlo si se desea que el nuevo sistema mantenga también información histórica.

Diagramas de Clases

Diagrama de Entidad-Relación

Diccionario de Datos

Los diagramas permiten construir

representaciones fáciles de interpretar, de

modo que puedan ser compartidas con el

usuario durante la validación.

El diagrama de clases y el diagrama ER son

alternativos.

El diccionario de datos es complementario a

las otras técnicas

Un diagrama de clases muestra la estructura estática de los elementos relevantes del sistema y sus relaciones, sin considerar el tiempo.

Aunque se llama diagrama de clases, las relaciones entre las clases son tan importantes para el modelo como las clases mismas.

Las relaciones son de asociación, agregación-composición y herencia.

El analista especifica los primeros niveles, que van a refinarse luego durante el diseño.

Una clase modela los atributos y el comportamiento de un conjunto de objetos relevantes del problema.

Nombre de la Clase

Nombre de la Clase

Atributos

Nombre de la Clase

Atributos

Servicios


Profesor

float salario()

legajo nombre fechaIngreso cargo

Profesor

int legajo String nombre Date fechaIngreso DP datosPostales String cargo

Profesor

boolean antes() Date diaAnterior()

Date

int dia, mes, año


La visibilidad es un elemento opcional en

el modelo y especifica si cada atributo o

servicio de la clase es visible fuera de la

clase o queda encapsulado.

Normalmente no se especifica en el

modelo lógico.

Cada atributo puede asociarse a un tipo y a un conjunto de restricciones sobre los valores. El tipo puede ser elemental o una clase.

En los LOO puros no existe el concepto de tipo. Cada atributo es un objeto de una clase.

En los modelos lógicos por lo general no se incluye el tipo.

La asociación es una relación estructural, estática entre clases.

Las asociaciones se explicitan en el diagrama de clase estableciendo un arco entre las clases relacionadas.

La asociación puede tener un nombre y opcionalmente una flecha que permite navegar entre las clases, es decir, nos indica la dirección para leer el nombre.

A

r1

E

r3

B

D

C

r2

Plan de Estudios

Materia

tiene

Materia

requiere

La multiplicidad es un elemento opcional e indica cuántas instancias de una clase estarán vinculadas a una instancia de la clase asociada.

La cantidad puede ser:

1

1 o más (1..*)

0 o 1 (0..1) (opcional)

0 o más (0..*) (opcional)

Un rango específico (m..n)

Director

Carrera

1 dirige 1

Una Carrera tiene un único Director y cada Director solo puede dirigir una Carrera. desea modelar información histórica. A lo largo del tiempo una Carrera va tener diferentes Directores y un mismo Director puede dirigir diferentes carreras.

Carrera

Plan de Estudios

1 tiene 1..*

Una Carrera puede estar asociada a uno o más Planes de Estudio, pero un Plan de Estudios corresponde a una única carrera.

Plan de Estudios

Materia

0..* tiene

20..45

Si el rango de valores no es estricto es preferible no establecerlo.

Plan de Estudios

Materia

* tiene

20..45

1 0..3 ofrece

Curso

Una materia se crea antes de dictarse por primera vez, puede existir la materia y no estar asociada a un Curso.

Plan de Estudios

Materia

* tiene

20..45

Curso 1 0..3 ofrece

Profesor

1..3 dicta

0..2

De acuerdo a este modelo no es posible crear un Curso sin asociarlo a un Profesor y a una materia.

Una clase asociación es una clase que modela la asociación entre otras clases y tiene atributos propios.

Por lo general se presenta en las relaciones con multiplicidad muchos a muchos.

A B

r 0..* 0..*

C

Materia Alumno

rinde 0..* 0..*

La clase Examen, que surge de la asociación entre Materia y Alumno (muchos a muchos), puede tener atributos, como fecha y nota.

Otra alternativa es que el analista identifique a Examen directamente como una clase, relacionada con las clases Materia y Alumno.

Examen

Materia Curso Aula

Profesor

La asociación entre Profesor, Materia y Aula se

modela con la clase Curso que tendrá atributos

propios.

Las relaciones de agregación y composición permiten modelar la dependencia entre clases que forman parte de un todo.

La agregación es una relación más fuerte que la asociación porque el comportamiento de una instancia de una clase depende del comportamiento de la instancia relacionada.

La composición es una relación aun más fuerte que la agregación porque la existencia de una instancia de una clase depende de la existencia de la instancia de la clase relacionada.

Director

Carrera

1 dirige 1

Cuando la multiplicidad es 1 existe una dependencia fuerte entre las clases.

Acta

ItemActa

Un acta contiene entre uno y más ítems. No existen

ítems que no estén asociados a un acta. Tampoco

actas sin ítems.

1 contiene

1..n

La herencia es un mecanismo que establece una relación de generalización-especialización entre clases.

D C

Profesor Director

Carrera

1 dirige 1

El Director de una Carrera debe ser un Profesor.

Una clase abstracta es aquella que no modela a ningún objeto del problema.

D E

*C

Por lo general se especifican durante el diseño.

Grado Posgrado

*Alumno

Plan de Estudios

Materia

0..* tiene

20..45

Curso 1 0..3 ofrece

Profesor

1..3 dicta

0..2

Alumno 0..* 0..* rinde

1 0..* inscripto

Cada plan de estudios tiene entre 20 y 45 materias inclusive Toda materia puede estar asociada a cualquier número de planes de estudio. Un curso se asocia exactamente una materia y al menos a un profesor y como máximo tres Un profesor puede no estar vinculado a ningún curso Todo alumno está ligado a exactamente un plan de estudios, puede no haberse inscripto en ningún curso.

La validación puede realizarse mediante una matriz en la que se “cruzan” casos de uso y clase y se registran diferentes tipos de operaciones.

Por ejemplo “C” crear, “L” leer, “M” modificar y “B” borrar”.

La generación y validación de la tabla permite detectar ausencias e inconsistencias entre casos de uso y conjuntos de entidades en el diagrama de clases.

Vehículo Mecánico Formulario Cuenta Corriente

Iniciar reparación

L L C

Registrar Factura

L C

…

En un sistema de mediana o gran escala es imposible incluir el conjunto completo de clases en un diagrama.

Un paquete es el recurso provisto por UML para organizar el conjunto de clases en forma jerárquica.

El DC va a ser refinado durante la etapa de

diseño agregando funcionalidad,

responsabilidades y nuevas clases asociadas.

El analista se concentra en el problema, el nivel

de abstracción es alto. No identificamos clases

como Fecha o String.

En esta etapa tampoco se decide como se van a

organizar las colecciones de datos.

Vehículo Patente NroChasis

Formulario Fecha Hora Inicial Hora Final

Propietario Nombre

Factura Nro Fecha Monto

Mecanico Nombre

Tipo Servicio Nombre

0..* 1..*

1 1

1 1..*

1

0..* 0..*

1

0..*

1

CtaCte Fecha Monto

1

0..*

Se registra el movimiento en cuente corriente pero no el cobro. La cobranza se realiza desde otros sistema, vinculado a través de la cuenta corriente. La factura no está imputada directamente a la cuenta corriente.



Propietario Nombre


Mecanico Nombre


0..* 1..*

1 1

1 1..*

1

0..* 0..*

1

0..*

1

CtaCte Fecha Monto

0..1 1

Una factura puede quedar pendiente imputada a un movimiento de la cuenta corriente. La vinculación del movimiento con el cliente es indirecta, a través de la factura.



Propietario Nombre


Mecanico Nombre


0..* 1..*

0 1

1 1..*

1

0..* 0..*

1

0..*

1 1

0..*

CtaCte Fecha Monto

Un diagrama entidad-relación es una representación visual que modela las entidades relevantes de un sistema, sus relaciones y atributos.

La técnica proviene del área de Bases de Datos pero se generalizó y se ha usado para modelar datos de cualquier tipo de sistema.

Aunque en la actualidad es más frecuente elaborar DC, el modelo de datos de los sistemas desarrollados hace algunos años suele estar especificado usando DER.

Una entidad es un objeto o cosa del mundo real que tiene una identidad propia, es decir, se distingue de otros objetos o cosas.

Libro Socio Editorial

Una entidad puede ser concreta o abstracta.

Plan de Estudios

Materia Carrera

Un atributo es una propiedad relevante para caracterizar a una entidad.

Libro Editorial

ISBN

Título Nombre

Contacto

Género

Socio

Código

Nombre

FNac

Nro

Tipo Doc

CantPag

Cada atributo toma un valor dentro de un dominio de valores.

Dos entidades que comparten los mismos atributos forman parte de una misma colección de entidades.

Dos entidades de una colección pueden tener los mismos valores en algunos atributos, pero no van a tener los mismos valores en todos los atributos.

El valor de un atributo puede ser simple, compuesto o multivaluado.

Se dice que el dominio puede ser un tipo provisto por el lenguaje o un tipo definido por el programador.

Algunos atributos se derivan de otros.

Es posible establecer restricciones sobre los valores e indicar si el dominio incluye un valor nulo.

Estas características no se especifican en el DER sino que se documentan por separado.

Socio

Código

Nombre

Fecha_Nac

Nro

Tipo_Doc

Código, Tipo_Doc y Nro tomarán valores simples

Nombre y FNac toman valores compuestos.

En ambos casos el dominio de valores puede estar provisto por el lenguaje.

Socio

Código

Nombre

Fecha_Nac

Tipo_Nro

Datos_ Postales

En este caso

Tipo_Nro

Datos_Postales

Toman valores compuestos, el dominio es un tipo definido por el programador

Este concepto no aparece en los LOO.

Una relación establece una asociación entre dos o más entidades.

Libro Socio Editorial publica retira

ISBN

Título

Código

Nombre

Nombre

Contacto

Género Fecha_Nac

Nro

Tipo_Doc

CantPag

Aunque las relaciones binarias son las más frecuentes, una relación puede asociar a tres o más entidades.

Artículo publica Autor

Revista

Una relación puede tener atributos

Libro Editorial publica retira

ISBN

Título Nombre

Contacto

Género FDev

FPres

Socio

Código

Nombre

FNac

Nro

Tipo_Doc

CantPag

Una participación total exige que cada entidad esté relacionada con al menos otra entidad

Artículo tiene Revista

Por lo general no se usa esta notación sino que se establece la cardinalidad.

Dado un conjunto de relaciones en el que participan dos o más conjuntos de entidades, la cardinalidad indica el número de entidades con las que puede estar relacionada una entidad dada.

Uno a Uno

Uno a Muchos

Muchos a Muchos

Uno a Uno: (1:1) Una entidad de A se relaciona únicamente con una entidad en B y viceversa

Aunque la técnica nombra 1:1 a esta cardinalidad, incluye en esta categoría la posibilidad de que haya entidades sin relacionar.

Carrera

Director

dirige

1

1

El arco rotulado especifica explícitamente si se trata de una relación Total (toda entidad debe estar relacionada) o Parcial.

Uno a Muchos: (1:N)Una entidad en A se relaciona con 1o muchas entidades en B.

Nuevamente los rótulos permiten indicar si la participación de cada entidad es total o parcial.

Plan de Estudios

tiene Carrera 1 1..n

Cada carrera tiene al menos un Plan de Estudios.

Cada Plan de Estudios está relacionado siempre con una única carrera.

Muchos a Muchos: (N:M) Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa

Materias

tiene

Plan de Estudios

0..n

1..m

Una materia puede estar relacionada a un plan de estudios, varios o ninguno.

Una clave es un subconjunto de atributos, que permite identificar a una entidad o relación unívocamente.

Una superclave un subconjunto de atributos que permite distinguir unívocamente cada una de las entidades de un conjunto de entidades. Si se añade un atributo al anterior subconjunto, el resultado seguirá siendo una superclave.

Socio

Código Nro

Tipo Doc

Una clave candidata es un atributo o conjunto mínimo de atributos que identifica unívocamente a una entidad.

Si una superclave deja de serlo quitando uno de los atributos que la componen, entonces es una clave candidata.

Socio

Nro

Tipo Doc

Socio

Código

Una clave primaria es una clave candidata elegida para identificar unívocamente las entidades en un conjunto de entidades.

Socio

Código

El análisis de un conjunto de entidades no es suficiente para asegurar qué atributos conforman una clave primaria.

Si una relación no tiene atributos la clave primaria de la relación es la unión de las claves primarias de las entidades asociadas por la relación.

Si una relación tiene atributos la clave primaria es la unión de las claves primarias de las entidades asociadas por la relación, junto con los atributos de la relación.

Libro Socio Editorial publica retira

ISBN

Título

CantPag Código

Nombre Nombre

Contacto

Género Fecha de

Devolución

FPres

FNac

Un mismo problema puede modelarse de maneras diferentes.

Cada género podría modelarse como una entidad.

Cada préstamo de un libro podría modelarse como una entidad intangible.

En este caso la entidad Préstamos estaría relacionada con Libro y con Socio, ninguna de estas relaciones tendría atributos.

La técnica ha sido extendida para incorporar:

Distinción entre entidades débiles y fuertes

Atributos agrupados en un rectángulo

Herencia

Agregación

Una entidad débil no tiene clave primaria.

Una entidad débil no puede existir sin participar en la relación, es decir, no puede ser unívocamente identificada solamente por sus atributos.

Una entidad fuerte o regular tiene una clave primaria.

La herencia es un intento de adaptación de estos diagramas al paradigma orientado a objetos.

La relación de herencia jerárquica se representa mediante un triángulo interconectado por líneas a las entidades.

La entidad conectada por el vértice superior del triángulo es la entidad "padre".

La agregación es una abstracción a través de la cual las relaciones se tratan como entidades de un nivel más alto.

Se utiliza para expresar relaciones entre relaciones.

Se representa englobando las relaciones y las entidades que participan en ella en un rectángulo.

El DER va a ser refinado durante la etapa de

diseño para transformar el modelo conceptual

en un modelo lógico.

El analista se concentra en el problema, el nivel

de abstracción es alto.

Por lo general el analista elabora un DER

cuando se decide que la especificación va a

evolucionar durante el diseño para producir un

modelo de base de datos relacional.

El diccionario de datos es una descripción textual de los datos, con una estructura basada en una plantilla.

Aunque no es un modelo formal, si es importante elaborarlo aplicando una metodología rigurosa.

Es un complemento de las representaciones visuales y debe ser consistente con ellas, como así también con el Glosario.

Describe tanto los datos almacenados como la entrada y salida.

Cada entidad del MER o cada clase de un DC va a estar asociada a una descripción en el DD, aunque no es necesario completar la plantilla para cada entidad o clase.

De cada atributo se incluye al menos el nombre y el tipo.

Se puede especificar de forma opcional las reglas de validación, las fórmulas de cálculo y los valores por omisión.

Nombre de la Clase

Nombre del Atributo

Tipo Rango Valor por omisión

Regla de Validación

Responsabilidades de la clase

Requisitos de la clase

Nombre del Flujo de Entrada de Dato

E o S Tipo Rango Valor por omisión

Regla de Validación

Nombre del Flujo de Salida de Dato

E o S Tipo Rango Valor por omisión

Las reglas de validación modelan restricciones y garantizan cierto nivel de integridad en los datos.

Las reglas de validación y las fórmulas pueden involucrar a varios atributos.

El análisis de las reglas del negocio permite identificar muchas de las reglas de validación y fórmulas.

Las siguientes reglas del negocio referidas a un Acta de Examen debe transformarse en reglas de validación para los datos:

El tipo de examen debe ser Regular o Libre.

La fecha de creación de un acta debe ser anterior a la fecha de examen

La nota debe ser entre 0 y 10

La cantidad de alumnos debe coincidir con la cantidad de renglones del cuerpo del acta.

El diccionario de datos mantiene un nivel de detalle que solo es posible alcanzar con lenguaje natural.

Son particularmente útiles para describir casos complejos.

En los diagramas es difícil especificar casos especiales o excepciones.

La principal desventaja de los DD es que tienden a crecer desmesuradamente y son difíciles de validar.

Para evitarlo no deberían describirse casos triviales.

El mayor riesgo es la inconsistencia, sobre todo cuando participan diferentes analistas.

En algunos proyectos el analista solo elabora el diccionario de datos y el diseñador genera las representaciones visuales.

En este caso el diccionario de datos no es un complemento de los requerimientos, sino que los requerimientos se especifican exclusivamente en el diccionario de datos.

Diagrama de

Contexto

Diagrama de

CU

Descripción

de CU

Diagrama de

Concep. Neg.

Diagrama de

Clases

La mayor parte de las aplicaciones generan reportes.

En general tienen un formato rígido, pueden incluir texto y gráficos.

El propósito y contenido se define durante el desarrollo de requerimientos y muchas veces impacta sobre la derivación de requerimientos de datos.

El diagramado puede establecerlo el usuario, el diseñador o puede estar impuesto por el contexto de la organización.

¿Qué reportes se generan actualmente?

¿Cuáles se agregan?

¿Cuáles deben ser modificados?

¿Quiénes son sus usuarios? ¿Para qué los usan?¿Qué decisiones se toman a partir de la información de cada reporte?

¿Con qué frecuencia se usa cada uno? ¿Depende de un evento?

¿Cuántas hojas puede demandar como máximo?

¿Cuál es el soporte? Se visualiza por pantalla, se imprime, se envía por mail, se exporta a una planilla de cálculo o a algún otro formato.

¿Hay restricciones de seguridad o privacidad que limiten el acceso a individuos específicos o clases de usuarios?

¿Qué fuentes de datos tiene el reporte?

¿Qué parámetros puede establecer el usuario?

¿Qué procesamiento se requiere? ¿Subtotales? ¿Contadores? ¿Ordenamiento?

¿Cuál es el contenido del reporte si no hay datos para mostrar?

¿Puede usarse una misma plantilla para distintos reportes?

Verificar que el sistema mantenga la información requerida por cada reporte o pueda computarla a partir de los datos almacenados.

Por ejemplo para poder generar un reporte que muestre una cuenta corriente imputada es necesario que el sistema haya registrado previamente que facturas fueron canceladas con cada recibo.

Anticipar el crecimiento

Un formato que es adecuado inicialmente puede no serlo cuando el volumen de información aumenta.

Un diagramado tabular puede ser adecuado para una cantidad reducida de items pero puede no ser adecuado cuando la cantidad aumenta.

Validar el glosario considerando los términos que aparecen en los reportes.

Identificar patrones

Varios usuarios pueden requerir reportes similares, definir formato común y parametrizar los aspectos que son diferentes.

Por ejemplo un certificado de alumno regular puede contener o no el promedio, con o sin aplazos, los exámenes pueden estar ordenados alfabéticamente o cronológicamente, puede incluir las materias cursadas o solo los finales.

Considerar si tienen que modificarse dinámicamente

Los reportes estáticos muestran la información que corresponde al instante en que se generó el reporte.

Los reportes dinámicos se actualizan automáticamente a medida que la información cambia.

Por ejemplo un tablero de control.

Decidir si se generan prototipos

Permiten que el usuario visualice el diagramado y decida qué características le agradan y cuáles no.

Código

Título Nombre, posición y datos fijos y variables del título

Propósito Breve descripción de la necesidad que satisface el reporte

Usuarios Clases de Usuarios interesados en el reporte

Privilegios Privilegios requeridos para generar cada reporte

Decisiones Decisiones que cada clase de usuario puede tomar a partir del reporte

Prioridad Prioridad respecto a otros reportes

Latencia Tiempo de entrega del reporte al usuario que lo requiere Actualidad de los datos incluidos en el reporte

Diagramado Tamaño de papel, orientación, márgenes

Gráficos e Imágenes

Tipos de gráficos e imágenes, tamaño

Encabezamiento y pie

Texto fijo y variable, Fecha Número de página, nombre del usuario que lo solicita, nivel de confidencialidad

Cuerpo Criterio de selección de dato, atributos Criterio de ordenamiento, fórmulas Criterio de paginado

Un tablero de control es un reporte que aparece en pantalla o impreso y permite visualizar información relevante y consolidada referida a la organización o un proceso.

Por lo general incluye algunos valores numéricos, probablemente organizados como una tabla, gráficos u otro tipo de imágenes que muestran algunos indicadores claves. Puede ofrecer también un texto breve.

En un tablero dinámico la información se modifica en tiempo real a medida que el estado interno de los datos se modifica.

La información debe permitir detectar situaciones que requieren tomar decisiones rápidas.

El usuario puede explicitar que necesita un tablero de control o puede proponerlo el analista luego de capturar los requerimientos para los reportes.

Es probable que la interpretación de un tablero requiera de algún entrenamiento.

En todos los reportes, pero más aun en los

tableros de control, el contenido es muy

importante, pero el diagramado también tiene

relevancia.

Tanto el contenido como el diagramado puede

parametrizarse, en cuyo caso se requiere un

usuario aun más entrenado.

Como en el caso de los reportes es necesario capturar restricciones, privilegios, prioridades y fundamentalmente analizar si con los datos almacenados es posible ofrecer los indicadores incluidos en el tablero.

Los prototipos son un excelente recurso para asegurar que el estilo y diagramado satisface las necesidades del usuario.

En proyectos en gran escala o en empresas dedicadas al desarrollo de sistemas se suele asignar un especialista para el diseño de interfaces de usuario.

En este caso será el responsable de diseñar los prototipos de todos los reportes, en particular el tablero de control, pero debe trabajar con usuarios representativos para conocer convenciones propias del dominio, con el analista para asegurar que la información pueda obtenerse a partir de los datos almacenados y con los implementadores para analizar el tiempo y los recursos que demanda.

Clase 11 Requerimientos para los Datos y para los reportescs.uns.edu.ar/materias/rs/downloads/CLASES...

Documents

Transcript of Clase 11 Requerimientos para los Datos y para los reportescs.uns.edu.ar/materias/rs/downloads/CLASES...