Está en la página 1de 45

Análisis y Diseño 106 Análisis

de Sistemas

ANÁLISIS

5.1 INTRODUCCIÓN

Identificación  Determinación de requerimientos


del Proyecto y  Estructuración de requerimientos
_ Selección  Generación de alternativas y solución

Iniciación del
Proyecto y
Planificación

Análisis

Diseño
Lógico

Diseño Físico

Implementación

Mantenimiento

El análisis es la primea fase del Ciclo de Vida del Desarrollo de Sistema (SDLC) donde
usted empieza a entender con profundidad la necesidad de cambio del sistema. Los sistemas
en la fase de análisis involucran una cantidad substancial de esfuerzo y costos, por ello se
debe emprenderse solamente después de que los ejecutivos o directores tienen decido que
el proyecto de desarrollo de sistemas bajo consideración, tiene méritos y proseguir durante
esta fase. La fase de iniciación y planeación de proyectos provee las bases para un buen
adelanto de decisión para el análisis y el plan básico del proyecto (PBP) provee la
estructura para conducir la fase del análisis. Como el análisis es grande e involucra muchos
procesos, se puede dividir en tres actividades principales:

 Determinación de requerimientos
 Estructuración de requerimientos
 Generación de alternativas y solución
Análisis y Diseño 107 Análisis
de Sistemas

1 2
Las notas de la entrevista,
Determinación los resultados del estudio Requerimientos Estructuración
de de
Requerimientos Requerimientos
Descripción actual y
alternativas del nuevo
Sistema

Archivo del
Planes del SI,
Proyecto
Planes del Análisis,
Requerimientos del
3
servicio del sistema, Nuevas alternativas
Justificación del de la descripción del Generación y
proyecto sistema Selección de
Alternativas
Recomendaciones estratégicas
para reemplazar el nuevo sistema

Figura 5-1

El propósito del análisis es determinar que información y servicios de procesamiento de


información son necesarios para el soporte de objetivos seleccionados y funciones de la
organización, consecuentemente, el análisis es fundamentalmente una actividad en el cual
los analistas capturan y estructuran la información en forma inteligente.

5.2 DETERMINACIÓN DE REQUERIMIENTOS


5.2.1 EL PROCESO DE DETERMINACIÓN DE REQUERIMIENTOS

Durante la determinación de requerimientos usted y otros analistas recolectan información


desde muchas fuentes como sea posible: desde los usuarios del sistema actual, desde la
observación de los usuarios y reportes, formularios y procesamientos. Todos los
requerimientos del sistema son cuidadosamente documentados y dispuestos para
estructurarlos.

La recolección de requerimientos de sistemas es como conducir cualquier investigación.


Existen algunas características para una buena determinación de requerimientos durante el
análisis del sistema y son:

 Impertinencia: Usted puede preguntar todo, como: ¿Todas las transacciones son
procesadas con el mismo método? ¿Nosotros podríamos permitir y animar que los
empleados trabajen para más de una sección, algún día?
Análisis y Diseño 108 Análisis
de Sistemas

 Imparcialidad: Su papel es encontrar la mejor solución u oportunidad a un problema


del negocio. Esto no es, por ejemplo, encontrar una manera para justificar la compra
de nuevo hardware o insistir en incorporar a usuarios en el nuevo sistema. Usted
debe considerar problemas ocasionados por todas las partes y debe intentar
encontrar la mejor solución organizacional.

 Necesidad de Relajarse: Asuma que algo es posible y elimina lo in factible. Por


ejemplo, no admita las declaraciones como esta, "nosotros siempre lo hemos hecho
de esta manera y así nosotros tenemos que continuar en la práctica. Las tradiciones
son reglas y políticas de formas diferentes. Las tradiciones probablemente
empezaron por una razón buena pero, como la organización y su ambiente cambia,
las tradiciones pueden convertirse en hábitos en lugar de procedimientos sensatos.

 Atención de detalles: Cada hecho debe ajustarse con otro hecho. Un elemento fuera
de lugar significa que el sistema final fallará en algún momento. Por ejemplo, una
definición imprecisa de un cliente, puede significar que usted depure a un cliente de
contacto vital para las ventas futuras.

 Refrán: El análisis es, en parte, un proceso creativo. Usted debe desafiarse, mirar la
organización de distintas maneras. Usted debe considerar cómo cada usuario ve su o
sus requerimientos. Usted debe tener el cuidado para no llegar a esta conclusión:
"Yo trabajé una vez en un sistema así que este nuevo sistema debe trabajarse de la
misma manera como el que construí antes"

5.2.2 Derivables y Resultados

El primer derivable de la determinación de requisitos es información es sus diversas


formas, que es recogida durante el proceso de determinación de requerimientos: las
transcripciones de las entrevistas; las notas de observaciones realizadas y análisis de
documentos; las repuestas analizadas de las encuestas; los juegos de formularios, informes,
descripciones del trabajo y otros documentos y salidas generadas por la computadora tales
como los prototipos del sistema.

La Tabla 5-1 lista ejemplos de información específica que podría recogerse durante la
determinación de requisitos.

Estos derivables contienen la información que usted necesita para el análisis del sistema
dentro del alcance del sistema que usted está desarrollando. Además, usted necesita
entender los componentes siguientes de una organización:

 Los objetivos del negocio, que y cómo el trabajo se hace.


 Al personal de información necesita hacer sus trabajos.
 Los datos (la definición, el volumen, el tamaño, etc.) que se manejan dentro de la
organización para apoyar los trabajos.
 Cuando, cómo y por quien los datos son movidos, transformados y guardados.
Análisis y Diseño 109 Análisis
de Sistemas

 La secuencia y otras dependencias entre los diferentes datos manejados en las


actividades.
 Las reglas que gobiernan, cómo los datos son manejados y se procesan.
 Políticas y pautas que describen la naturaleza del negocio, mercado y el ambiente en
que opera.
 Los eventos importantes que afectan los valores de los datos y cuando los eventos
ocurren.

Tabla 5-1 Derivables para la Determinación de Requerimientos


1. Información recopilada de la conversación con observaciones de los usuarios:
Trascripción de la entrevista, respuestas a las encuestas, la notas de la
observación, reuniones.
2. Información escrita existente: La misión del negocio y declaración de la
estrategia, formularios del negocio e informes desplegados por la computadora,
manuales de procedimientos, descripción del trabajo, manuales de procedimiento,
diagramas de flujo y documentación de sistemas existentes, los informes del
consultor.
3. Información basado en computador: Los resultados de las sesiones del Diseño
de Aplicación de Juntura, transcripciones o archivos de las sesiones de los grupos
de soporte del sistema, informes de sistemas existentes y los despliegues e
informes de los prototipos del sistema.

Como debe ser obvio, tales cantidades grandes de información deben organizarse para ser
útil. Éste es el propósito de la próxima fase - la estructuración de requisitos.

5.2.2 Métodos tradicionales para la determinación de


requerimientos

El centro del análisis de sistemas es la recopilación de información. Usted debe recopilar la


información acerca del sistema de información que está usándose actualmente y cómo a los
usuarios les gustaría mejorar los sistemas actuales y el funcionamiento organizacional con
un nuevo sistema de información. Una de las maneras más fácil de conseguir esta
información, es hablar con las personas que son directamente o indirectamente involucradas
en las diferentes partes de la organización afectadas por los posibles cambios del sistema:
los usuarios, gerentes, etc. Otra manera de averiguar sobre el sistema actual es recoger
copias de documentación pertinente a los sistemas actuales y procesos del negocio. Usted
aprenderá sobre la documentación recopilada del sistema actual y funcionamiento de la
organización en forma de procedimientos, formularios, informes. Los métodos tradicionales
de recopilación de información del sistema se listan en la tabla 5-2.
Análisis y Diseño 110 Análisis
de Sistemas

Tabla 5-2 Métodos Tradicionales de Recopilación de Requerimientos del Sistema


 En las entrevistas individuales las personas informan sobre el funcionamiento y
problemas del sistema actual y necesidades para el sistema en las actividades
organizacionales futuras.
 Personas que estudian las encuestas para descubrir problemas y requerimientos.
 Entrevistas grupales de personas con diversas necesidades, encontrar correlaciones
y contrastes entre los requerimientos del sistema.
 Observar a empleados en los momentos seleccionados para ver como los datos son
manejados y que información necesita las personas para hacer sus trabajos.
 Estudio de los documentos del negocio para describir los problemas, políticas,
reglas y direcciones así como el ejemplo concreto de uso de datos e información en
la organización

TÉCNICA DE LA ENTREVISTA

Las entrevistas constituyen el medio para obtener información sobre: los requisitos del
usuario, el funcionamiento del sistema actual, la organización del sistema, las
responsabilidades y funciones de los usuarios, etc.

En muchas ocasiones puede ser conveniente sustituir la tradicional entrevista “cara a cara”
con el usuario, por reuniones en grupo con un conjunto de usuarios especializados en las
funciones a tratar por el sistema. Esto tiene especial importancia, en el caso de que un
sistema abarque distintos sectores de la Organización, como por ejemplo, distintas unidades
que realizan funciones similares y el objetivo es crear un estándar para unificar el
procedimiento.

Así mismo, otro ejemplo que será de utilidad en la realización de reuniones en grupo, es en
la elaboración de un Plan de Sistemas de la Organización, dado que en ese caso, se plantean
cuestiones como la especificación de objetivos de la Organización a largo plazo, las
posibles necesidades de información, las nuevas funciones a desarrollar, etc. La realización
de reuniones en grupo permite establecer mejor las prioridades y objetivos de la
Organización.

Desarrollo de la Entrevista

A continuación se dan algunas recomendaciones generales sobre la técnica de entrevistas,


haciendo énfasis en dos aspectos esenciales de las mismas:

 Preparación de los Guiones para la entrevista.


 Consolidación de la entrevista.

Preparación de Guiones

Antes de realizar una entrevista es imprescindible enviar al usuario a entrevistar, un guión


previo sobre los puntos a tratar. Dicho guión ha de ser suficientemente detallado para
cubrir todos los aspectos de interés, y dar oportunidad al usuario a preparar documentación
Análisis y Diseño 111 Análisis
de Sistemas

sobre el sistema. Sin embargo, debe existir un compromiso en cuanto a la extensión del
guión o cuestionario previo, ya que un excesivo detalle en el mismo puede provocar
rechazo por parte de los usuarios (ver figura 5-2).

¿Qué preguntar?

Es importante elaborar el guión, atendiendo al perfil y a las responsabilidades del usuario a


entrevistar. A continuación, se exponen una serie de consideraciones sobre los aspectos a
tener en cuenta, en función de dicho perfil de usuarios:

1. Entrevistas a los responsables de área.

Funciones que realiza su departamento o grupo.


Sistemas de Información actuales (ya sean manuales o mecanizados): entradas, salidas,
funcionalidad.
Relaciones o salidas a otros sistemas, definiendo:

a) Destino de los datos (departamento o grupo dentro de un departamento, y si es


posible el nombre del sistema que recibe la salida).
b) Medios empleados (papel, intercambio electrónico de datos, disquete, cinta
magnética).
c) Frecuencia (tiempo real, varias veces al día, diariamente, semanalmente, etc.).

Nivel de satisfacción técnica con el sistema de información actual. Se establecerá una


evaluación global sobre los siguientes aspectos:

a) Disponibilidad de los sistemas de información.


b) Tiempos de respuesta.
c) Facilidad de uso.

Identificar al resto de los usuarios del departamento o grupo que deberá participar en
futuras entrevistas.

Al final de la entrevista es importante devolver a los entrevistados un acta donde se


resuman los puntos tratados.

2. Entrevistas al resto de los usuarios.

El objeto de estas entrevistas es detallar aspectos funcionales más concretos. El guión para
estas entrevistas debería contemplar:

1) Situación Actual. Descripción de los sistemas de información actualmente implantados


(ya sean manuales o informatizados). Incluir:

a) Entorno físico/lógico existente.


Análisis y Diseño 112 Análisis
de Sistemas

b) Por cada tipo de entrada describir su origen (departamento, grupo o sistema en caso
de que exista, lo genera), los datos involucrados, el soporte utilizado (papel,
intercambio electrónico de datos, disquete, cinta magnética) y la frecuencia (tiempo
real, varias veces al día, diariamente, semanalmente).

c) Procesos y funciones realizados por dichos sistemas.

d) Por cada tipo de salida describir el destino (departamento, grupo de departamento o


sistema que lo recibe, si existe), los datos involucrados.

 Soporte (papel, intercambio electrónico de datos, disquetes, cinta


magnética).
 Frecuencia (tiempo real, varias veces al día, diariamente, semanalmente,
etc.)
 Volumen de información manipulada.

e) Por sistema de información, detallar los sistemas de almacenamiento de datos


involucrados, y para cada uno de ellos especificar:

 Tipos de datos implicados.


 Principales ventajas e inconvenientes.

f) Nivel de satisfacción técnica con los sistemas actuales. La valoración incluirá


aspectos como:

 Disponibilidad de los sistemas de información.


 Tiempos de respuesta.
 Facilidad de uso.
 Tiempo de espera si se piden modificaciones.

2) Requisitos del Nuevo Sistema.

a) Nuevos procesos/funciones a realizar por el sistema.


b) Prioridades de esos procesos/funciones.
c) Nuevas consultas deseadas, incluyendo:

 Datos involucrados.
 Origen y destino de esos datos.
 Frecuencia.

d) Nuevos informes deseados.


e) Necesidades de seguridad sobre los datos.
f) Factores críticos de éxito.
Análisis y Diseño 113 Análisis
de Sistemas

Consideraciones

Debe tenerse en cuenta que lo expuesto en esta técnica es sólo una visión general de los
aspectos más relevantes que deben ser tratados en cada tipo de entrevista. Para cada
proyecto, deberá confeccionarse un guión detallado de las entrevistas que se realicen, según
sea:

i. El tipo de proyecto.
ii. El usuario entrevistado.
iii. La experiencia del entrevistador y su conocimiento del sistema analizado.

a. El guión de la entrevista se entregará con suficiente anticipación al responsable de


usuarios, para que éste pueda garantizar su distribución a las personas involucradas.
b. En la realización de una entrevista, se abordarán los puntos a tratar desde una visión
general, al principio, para centrarse gradualmente en aspectos más detallados.

Consolidación de la Entrevista

Una vez realizada la entrevista con el usuario, es conveniente depurar y consolidar los
resultados de la misma, para asegurar que se han comprendido bien las especificaciones del
usuario sobre el conjunto de procedimientos de trabajo del sistema actual, así como sobre
los requisitos que debe satisfacer el nuevo sistema.

Para ello se utilizarán técnicas de representación para ilustrar el funcionamiento del sistema
actual, mediante un dibujo libre, que permita contrastar con el usuario, el flujo de la
información a través del sistema, así como las diversas tareas y responsabilidades en el uso
de esa información. Además, se especificarán los requisitos de usuario de una forma
sencilla y medible, de manera que se pueda asignar prioridades a dichos requisitos, y se
validarán conjuntamente con el usuario, dichas prioridades.

Por último, en el caso que se disponga de las herramientas necesarias, se podrán elaborar
prototipos o maquetas simples del nuevo sistema, en los que figuren:

 Las pantallas de que consta.


 Los informes a obtener.
 La simulación de las funciones que realiza.
 La apariencia externa del mismo.

Estos prototipos ayudarán al usuario a especificar y concretar sus necesidades, a medida


que se sigue avanzando en las demás etapas de desarrollo del sistema.
Análisis y Diseño 114 Análisis
de Sistemas

Bosquejo de la entrevista

Entrevistado: Entrevistador:
Nombre de la persona que se entrevista Nombre de la persona que llevará a cabo la
entrevista.

Localización / Medio: Datos de la cita:


Oficina, sala de conferencia o número de Fecha Inicial:
teléfono. Fecha Final:

Objetivos: Notificaciones:
Qué datos para recopilar Fondo / la experiencia de la entrevista
En que beneficia el acuerdo Opiniones conocidas de la entrevista
Que áreas para explicar

Agenda: Tiempo aproximado:


Introducción 1 minuto
Fondo del Proyecto 2 minutos
Visión de la entrevista
Tópicos a se cubiertos 1 minuto
Permiso para grabar el registro
Tópico 1 Preguntas 5 minutos
Tópico 2 Preguntas 7 minutos
...
Resumen de los puntos principales 2 minutos
Preguntas de la entrevista 5 minutos
Cierre 1 minuto

Observaciones Generales:

Entrevistado parecía ocupado – probablemente se necesita llamar en pocos días para


continuar - a las preguntas sólo respuestas cortas. El PC se apagó – probablemente no es
una usuario regula de la PC.

Problemas irresolubles, Tópicos no Cubiertos:

Él necesita observar los informes de las ventas de 1996. Él identificó el problema de cómo
los productos son devueltos, pero nosotros no teníamos tiempo para discutir.

a)
Análisis y Diseño 115 Análisis
de Sistemas

Entrevistado: Fecha:

Preguntas: Notas:

Pregunta 1: Respuesta:

Si, yo pido un informe semanalmente


¿Usted ha usado las ventas de mi línea del producto.
actuales que rastrean el sistema?
En ese caso, ¿que a menudo? Observaciones:

Parecía ansioso – puede haber


terminado – estimando uso de
frecuencia

Pregunta 2: Respuesta:

¿Qué es lo mínimo que le gusta Las ventas son mostradas en unidades, no


de este sistema? dólares.

Observaciones:

El sistema puede mostrar ventas en


dólares, pero el usuario no sabe.

b)

Figura 5-2

TÉCNICA DEL CUESTIONARIO

El cuestionario es el medio de comunicación entre el que solicita los datos y el


respondiente, se suele estructurar en secciones y estas en preguntas que deberían ser fáciles
de comprender y contestar.

El cuestionario debe:

a) Ser fácilmente manejable; en particular se evitará la preocupación excesiva de un


ahorro de espacio.
b) Tener una estructura, sucesión de preguntas y amplitud que mantenga el interés de
los respondientes. Según Morton Williams, si estas condiciones se cumplen, el
interés puede mantenerse durante al menos 40 minutos, casi para cualquier materia.
c) Contener un vocabulario apropiado para el nivel cultural al que va dirigido.
d) Ser objeto de un ensayo, posiblemente entre 30 y 100 entrevistados, según la
materia de que se trata.
Análisis y Diseño 116 Análisis
de Sistemas

Diseño del Cuestionario

La habilidad de crear buenos cuestionarios, es una habilidad que se mejora con la práctica y
experiencia. Porque las preguntas son escritas, ellas deben estar sumamente claros
significativos y lógico en la sucesión. Cuando una apersona está completando un
cuestionario, él o ella sólo tienen las preguntas escritas para interpretar y contestar. Por
ejemplo, si son preguntas cerradas expresadas de esta manera:

¿Qué a menudo realiza las copias de respaldo de los archivos de la computadora?

a. Frecuentemente
b. A veces
c. Escasamente
d. Nunca

Hay dos fuentes de ambigüedad por lo menos en la redacción de la pregunta. La primera


fuente de ambigüedad son las categorías ofrecidas para la respuesta: La única respuesta no
ambigua es “Nunca”. “Escasamente” podría significar algo de una vez por año o por mes,
dependiendo quien contesta la pregunta. “A veces” podría cubrir el mismo rango de
posibilidades como “Escasamente”. “Frecuentemente” podría ser algo de una vez por hora
o por semana. La segunda fuente de ambigüedad está en la propia pregunta. El término
“archivos de la computadora”, ¿solo pertenecen a aquellos en disco duro? ¿O también
aquellos archivos que yo he guardado en el floppy? ¿Qué si yo tengo mas de una PC en mi
oficina? ¿Y qué sobre los archivos que yo he guardado en la mini computadora? Yo no
realizo el backup de esos archivos, el operador del sistema lo hace en una base regular para
todo las mini computadoras.

Una manera menos ambigua de expresar la pregunta y sus categorías de la respuesta serían
algo así:

¿Qué a menudo realiza usted el backup de los archivos de la computadora guardados en el


disco duro en el PC que usted usa por encima del 50% de tiempo de su trabajo?

a. Frecuentemente (por lo menos una vez por trabajo)


b. A veces (de una a tres veces por mes)
c. Escasamente (una vez por mes o menos)
d. Nunca

5.2.3 ANÁLISIS DE PROCESOS Y DOCUMENTOS

¿Qué es un proceso?

No existe producto y/o servicio sin un proceso. De la misma manera, no existe proceso sin
un producto o servicio. Antes de continuar se define lo siguiente:
Análisis y Diseño 117 Análisis
de Sistemas

Sistema. Controles que se aplican a un proceso para tener la seguridad de que éste
funcione eficazmente y eficientemente.

Proceso. Cualquier actividad o grupo de actividades que emplee un insumo, le


agregue valor a éste y suministre un producto a un cliente externo o interno. Los
procesos utilizan los recursos de una organización para suministrar resultados
definitivos.

Proceso de Producción. Cualquier proceso que entra en contacto físico con el


hardware o software que se entregará a un cliente externo hasta aquel punto en el
cual el producto se empaca (por ejemplo, fabricación de computadora, preparación
de alimentos para el consumo masivo de los clientes, refinación de petróleo,
transformación de hierro en acero).

Proceso de la Empresa. Todos los procesos de servicios y los que respaldan a los de
producción (por ejemplo, de pedidos, procesos de cambio en ingeniería, de nómina,
diseño del proceso de manufactura). Un proceso de la empresa consiste en un grupo
de tareas lógicamente relacionadas que emplean los recursos de la organización para
dar resultados definidos en apoyo a los objetivos de la organización.

Función. Un grupo dentro de la organización funcional. Funciones características


serían ventas y mercado, contabilidad, ingeniería de desarrollo, compras y garantía
de calidad.

Departamento. Un gerente o supervisor y todos los empleados que le presentan


informes.

Al emplear estas definiciones, puede ver casi todo lo que hacemos es un proceso y que los
de la empresa desempeñan un papel importante en la supervisión económica de nuestras
organizaciones.

Edward J. Kane ex director de calidad en IBM Corporation, era muy activo en la aplicación
de estos conceptos en las áreas administrativas de IBM, Kane declaró lo siguiente:

Tomar el pedido de un cliente, llevarlo de un sitio a otro dentro de la planta, distribuir estos
requerimientos y llevarlos al piso de producción, es una actividad que, por si sola, implica
30 etapas de subprocesos. Cuentas por cobrar tiene más de 20 etapas. El procesamiento de
información en si es una disciplina completa, con muchos procesos que conlleva desafíos,
integrados dentro de una sola actividad total.

A continuación se presenta una lista de procesos típicos de la empresa definidos por IBM.
Análisis y Diseño 118 Análisis
de Sistemas

Tabla 5-3
Función Nombre del proceso
Desarrollo Manejo de índices
Diseño de control acústico
Desarrollo de comunicación avanzadas
Diseño de componentes de cable
Gerencia de confiabilidad
Objetivo de costo
Prueba de diseño
Revisión de diseño y materiales
Revisión de documentos
Especificación del diseño a alto nivel
Diseño industrial
Coordinación entre divisiones
Diseño lógico y verificación
Calificación de componentes
Diseño del sistema de energía
Gerencia del producto
Divulgación del producto
Lanzamiento
Diseño del producto a nivel del sistema
Confiabilidad y utilidad del sistema
Requerimientos del sistema
Diseño de instrumentos
Diseño interactivo de sistemas para el usuario
Análisis de la competencia
Operación de ingeniería
Desarrollo de la información
Planeación de interconexión
Desarrollo de interconexión de productos
Instrumento de diseño físico
Diseño de sistemas
Gerencia de cambio en ingeniería
Desarrollo de producto
Control del desarrollo del proceso
Desarrollo de instrumentos
Control del desarrollo del proceso
Desarrollo electrónico
Requerimiento de la fase 0
Distribución Recepción
Embarque
Almacenamiento
Servicio de campo y apoyo
Teleprocesamiento y control
Despacho de partes
Vehículo de fuerza motriz
Análisis y Diseño 119 Análisis
de Sistemas

Mercaderías aseguradas y rescatadas


Transporte
Recibos de producción
Desembolsos
Manejo de inventarios
Manejo de inventario físico
Contabilidad financiera Control de libro mayor
Control financiero
Nómina
Impuestos
Precios de transferencias
Cuentas por cobrar
Contabilidad con base en acumulaciones
Contabilidad de ingresos
Cuentas por pagar
Control efectivo
Contabilidad de gastos por empleados
Control de activos fijos
Distribución de trabajo
Contabilidad de costos
Aplicación financiera
Activos fijos y asignación
Contabilidad y facturación entre compañías
Control de inventarios
Apoyo de gestiones
Control financiero
Planeación financiera Control de asignación
Control de presupuesto
Estimación de costos
Planeación financiera
Precios de transferencias
Control de inventario
Planeación comercial
Gerencias de contratos
Perspectiva financiera
Sistema de Información Metodología para el desarrollo de aplicaciones
Controles para administración de sistemas
Evaluación a nivel de servicios

Control de producción Proceso de consignación


Manejo de servicios y pedidos del cliente
Involucramiento inicial de manufactura y lanzamiento de
productos
Ejecución de control efectivo
Apoyo de campo de partes
Planeación y pedidos de partes
Análisis y Diseño 120 Análisis
de Sistemas

Gerencia de planeación y programación


Gerencia de rendimiento de los volúmenes en planta de la
empresa
Partes sensibles a la locación
Dirección de sistema de trabajos en proceso
Distribución
Proyección de inventario
Planeación de nuevos productos
Precisión de trabajos en proceso
Compromiso con el plan base
Registro del proceso de manufactura
Compras Modificación y cancelación
Aceleración
Facturas y pago
Elección de proveedores
Costo
Despacho
Calidad
Relaciones con proveedores
Contratos
Adquisición de laboratorios
Órdenes de no producción
Pago a proveedores
Transferencia de procesos entre plantas
Personal Beneficios
Compensaciones
Relaciones con empleados
Empleo
Igualdad de oportunidades
Recursos administrativos
Desarrollo gerencial
Servicios médicos
Investigación de personal
Servicio de personal
Ubicación
Registros
Sugerencias
Desarrollo e investigación administrativa
Programas de personal
Evaluación del personal
Gerencias de recursos
Programación Productos de sistema distribuidos
Centro de programación
Desarrollo de software
Ingeniería de software
Productos para la producción de software
Análisis y Diseño 121 Análisis
de Sistemas

Calidad Calificación de nuevos productos


Calidad de proveedor
Servicios en la locación Instalaciones para solicitudes de modificaciones
Misceláneos Costo de la calidad para manufactura de cajas
Estimación de los costos de servicios
Planeación de la locación

Diagrama de Flujo Administrativo

La imagen vale más que mil palabras. Si podemos modificar este viejo proverbio y
ampliarlo un poco para que cubra los procesos de la empresa, podríamos decir: “Un
diagrama de flujo vale mas que mil procedimientos”. Un diagrama de flujo, conocido
también como diagramación lógica o flujo, es una herramienta de gran valor para entender
el funcionamiento interno y las relaciones entre los procesos de empresa.

Ejemplo: Diagrama de flujo funcional del proceso interno de búsqueda de empleados.

Actividad Área de Actividad Área de


responsabilidad responsabilidad
1. Reconozca la necesidad. Jefe de área 9. Entreviste a los candidatos y Jefe
Complete el análisis de ingreso revise los detalles del cargo.
anual. Prepare la solicitud del
personal.
2. Evalué el presupuesto. En caso Contralor 10. Notifique al departamento de Jefe
afirmativo, firme la papeleta para la personal sobre los resultados de la
solicitud de personal. En caso entrevista.
negativo, devuelva todo el paquete
en carta de rechazo al jefe.
3. Realice investigación interna Departamento de personal 11. Si el candidato apto está Departamento de personal
disponible, haga una oferta de
empleo. Sino lo está, inicie el
proceso de contratación externa.
4. Si existe candidatos internos, Departamento de personal 12. Evalué la oferta de empleo y Candidato
entregue una lista a la gerencia. Si notifique al departamento de
no, inicie el proceso de contratación personal sobre la decisión del
externa. candidato
5. Revise los documentos de los Jefe 13. En caso afirmativo, notifique Departamento de personal
candidatos, y prepare una lista de los al jefe que el cargo ha sido
que van a entrevistarse. ocupado. Si no lo ha sido, pase a
la actividad 14.
6. Haga que los jefes de los Departamento de personal 14. ¿Hay otros candidatos Departamento de Personal
candidatos revisen el cargo con los aceptables? Sino los hay, inicie el
empleados y determinen que proceso de contratación externa.
empleados están interesados en la
posición.
7. Notifique al departamento de Candidato 15. Haga que el nuevo jefe se Jefe
personal sobre los candidatos ponga en contacto con el jefe
interesados en la posición. actual del candidato, y disponga
lo necesario par que el candidato
se incorpore al trabajo.
8. Organice una reunión entre jefes y Departamento de personal
candidatos.
Análisis y Diseño 122 Análisis
de Sistemas

Gerente Dpto. de Personal Candidato Contralor

si
Inicio 1 2

no

4
si

6 7
A

9 8

10 si 12
11

no

si
Fin 15 13

no

si
14

no
Análisis y Diseño 123 Análisis
de Sistemas

Donde:

Operación. Se usa para denotar cualquier clase de actividad.


Normalmente usted debe incluir en el rectángulo una breve
descripción de la actividad.

Punto de decisión. Coloque un diamante en aquel punto de


. proceso en el cual deba tomarse una decisión.

Inspección. Utilice un círculo grande para indicar que el flujo del


proceso se ha detenido, de manera que puede evaluarse la calidad
de output. Típicamente involucra una inspección realizada por
alguien que no se a la persona que efectuó la actividad previa.
Este círculo también puede representarse para el punto en el cual
se requiere una firma.

Documentación. Utilice este símbolo par indicar que el output de


una actividad incluyó información registrada en papel (por
ejemplo, informes escritos, cartas o impresión de computadora)

Formalización de Requerimientos

En este punto se propone la generación de plantillas para cada uno de los requerimientos
detectados con el siguiente esqueleto:

Referencia: Consistirá en un código de referencia para normalizar la documentación.

Nombre: Nombre que se le da al requerimiento. No mas de una línea o línea y media. En


lenguaje natural.

Descripción detallada: Comentar con todo tipo de detalles como se realiza ese
requerimiento y que pasos se dan para obtenerlo haciendo referencia en todo momento a los
documentos involucrados en el tema.

Documentación asociada: Se anexarán todos los documentos que estén relacionados


con el requerimiento.

Evaluación actual: Grado actual de satisfacción del proceso que se realiza para obtener
este requerimiento, aquí se contempla la opinión del usuario y los problemas
(frecuentemente existen) que éstos detectan en el proceso. Si proponen soluciones
alternativas también se tienen en cuenta.

Necesidades de información detectadas: Normalmente siempre hay nuevas necesidades


de información sobre los requerimientos que sería deseable de satisfacer, aquí se reflejan y
Análisis y Diseño 124 Análisis
de Sistemas

se comenta como hacerlo. Pueden existir requerimientos que en este apartado no tengan
ninguna observación, aunque no es lo más frecuente.

Ejemplo

Referencia: R96/02.

Nombre: Registro/Atención de avisos.

Descripción detallada: Puede ocurrir que un cliente detecte una anomalía en el funcionamiento de su
ascensor o ascensores, normalmente el cliente llama a la oficina central donde se registra el aviso en la hoja
de recepción de avisos (D96/02). La persona responsable de coger los avisos llama por emisora a algún
operario que pertenezca al grupo de avisos para que vaya a resolver el problema. Una vez el operario ha
atendido el aviso rellena un parte de intervención (D96/03) que lleva a la oficina central, donde es completado
por el personal administrativo indicando el tipo de contrato (M=mantenimiento normal, MS=mantenimiento
semi-riesgo, MT=mantenimiento todo-riesgo) que tiene el cliente para ver si hay que facturar o no.

Documentación asociada: Los documentos involucrados son los siguientes

D96/02 Hoja de recepción de avisos


D96/03 Parte de intervención

Evaluación actual: Grado de satisfacción medio. Se da un tiempo de respuesta aceptable pero se considera
que se puede mejorar.

Necesidades de información detectadas: Muy interesante el registrar la información de los avisos donde
quede claramente reflejada el día y hora en que se producen, ello permitiría que se pudiesen obtener
estadísticas mensuales para averiguar cuales son los días y horas críticas de atención así como el tiempo
medio invertido por un operario en un aviso. De esta forma se podría racionalizar recursos (operarios,
telefonistas,...) para dar un servicio mas adecuado a nuestros clientes.
Análisis y Diseño 125 Análisis
de Sistemas

5.3 ESTRUCTURACIÓN DE REQUERIMIENTOS

5.3.1 MODELO DE PROCESOS

El modelo de procesos involucra la representación gráfica de las funciones o procesos, el


cual captura, manipula, guarda y distribuye datos entre un sistema y su ambiente y entre los
componentes dentro de un sistema. Una forma común de modelar los procesos es el
diagrama de flujo de datos (DFD). Durante muchos años se han desarrollado muchas
herramientas diferentes para el modelo de procesos.

El diagrama de flujo de datos es una de las muchas notaciones que es llamada técnica
estructurada de análisis. Aunque no todas las organizaciones usan cada una de estas
técnicas., colectivamente las técnicas como diagramas de flujo de datos han tenido un
impacto significante en la calidad del proceso de desarrollo de sistemas.

5.3.2 DERIVABLES Y RESULTADOS

En el análisis estructurado, el primer derivable del modelo de procesos es un conjunto


coherente de diagramas de flujo de datos interrelacionados. La tabal 5-4 proporciona una
lista más detallada de los derivables que es resultado de estudiar y documentar el proceso
de un sistema.

Tabla 5-4 Derivables para el modelo de procesos


1. Diagrama de Flujo de Contexto (DFD)
2. DFDs del sistema físico actual
3. DFDs del sistema lógico actual
4. DFDs del nuevo sistema lógico
5. Descripción completa de los DFD

Diagrama de Flujo de Contexto (DFD): Un diagrama de contexto muestra el alcance del


sistema, indicando qué elementos están dentro y cuales están fuera del sistema.

DFDs del sistema físico actual: Los diagramas de flujo de datos del sistema físico actual
especifican que personas y tecnologías son usadas y en que procesos, para mover y
transformar los datos, aceptando entradas y produciendo salidas. Estos diagramas se
desarrollan con suficiente detalle para entender el sistema actual y determinar como
convertir el sistema actual en uno de reemplazo en el futuro.

DFDs del sistema lógico actual: Tecnología independiente o lógico, diagramas de flujo de
datos del sistema actual muestran que procesos de datos son realizados por el sistema de
información actual.

DFDs del nuevo sistema lógico: La transformación de datos o flujo, estructuras y los
requerimientos funcionales del nuevo sistema son representados en diagramas de flujo de
datos lógicos.
Análisis y Diseño 126 Análisis
de Sistemas

Descripción completa de los DFD: Las entradas para todos los objetos incluidos en todos
los diagramas son incluidos en el diccionario del proyecto.

Esta progresión lógica de entregables le permite entender el sistema existente. Usted puede
resumir este sistema en sus elementos esenciales para mostrar la manera en que el nuevo
sistema debe encontrar la información que debe procesar para los requerimientos
identificados durante la determinación de requerimientos. Recuerde, los entregables del
modelo de procesos, simplemente están declarando lo que usted aprendió durante la
determinación de requerimientos, en los pasos posteriores del ciclo de vida en el desarrollo
del sistema, usted y otros miembros del equipo del proyecto tomarán decisiones sobre
como el nuevo sistema entregará exactamente estos nuevos requerimientos especificados en
el manual y las funciones automatizadas. Puesto que, la determinación de requerimientos y
la estructuración, son a menudo pasos paralelos, los diagramas de flujo de datos
descomponen de lo mas general a lo mas detallada del sistema actual y el reemplazo del
sistema se entiende muy bien.

5.3.3 MECANISMO DEL DIAGRAMA DE FLUJO DE DATOS

Los diagramas de flujo de datos son las herramientas de diagrama versátiles. Con sólo
cuatro símbolos, usted puede usar diagramas de flujo de datos para representar ambos
sistemas de información, físico y lógico. Los diagramas de flujo de datos (DFDs) no son
tan buenos, como los diagramas de flujo para representar los detalles de los sistemas
físicos, por otro lado, los diagramas de flujo no son muy útiles para describir los flujos de
información completamente lógicos. De hecho, los diagramas de flujo se han criticado por
los defensores del análisis y diseño estructurado porque tiene una orientación muy física.
Los símbolos del diagrama de flujo principalmente representan el equipo computacional
físico, tales como las tarjetas perforadas, terminales, y carretes de cinta. Consistente con la
filosofía de compromiso incremental del SDLC, usted debe esperar hacer cambios en la
tecnología y decidir sobre las características físicas de un sistema de información hasta que
usted esté seguro que todos los requerimientos funcionen correctamente y sean aceptados
por los usuarios y por otros.

Los DFDs no comparten este problema de diseño físico prematuro, porque ellos no cuentan
con símbolos para representar específicamente el equipo físico computacional. Ellos son
más fáciles de usar que los diagramas de flujo, ellos involucran sólo cuatro símbolos
diferentes.

Un flujo de datos puede entenderse mejor como datos en movimiento, la forma como se
desplaza de un lugar a otro en un sistema. Un flujo de datos podría representar los datos
sobre una orden del cliente o una nómina de cheques. Un flujo de datos también podría
representar los resultados de una pregunta a una base de datos, los contenidos de un
informe impreso, o datos sobre una entrada de datos en la computadora y la forma de
despliegue. Un flujo de datos son datos que se mueve al mismo tiempo. Así, un flujo de
datos puede componerse de muchas piezas individuales de datos que se generan al mismo
Análisis y Diseño 127 Análisis
de Sistemas

tiempo y fluyen juntos a destinos comunes. Un archivo de datos es un dato en reposo. Un


archivo de datos puede representar una de muchas localizaciones físicas diferentes para los
datos, por ejemplo, un archivo, una o más computadora basado en archivo(s), o un
cuaderno. Para entender el movimiento de los datos y manejo en un sistema, la
configuración física no es muy importante. Un archivo de datos podría contener los datos
sobre cliente, los estudiantes, pedidos de clientes, o facturas del proveedor. Un proceso es
el trabajo o las acciones que se realizaron en los datos para que ellos sean transformados,
guardados, o distribuidos. Al modelar el proceso de datos de un sistema, no le importa si un
proceso se ha realizado manualmente o por una computadora. Finalmente, una
fuente/destino es el origen y/o destino de los datos. La fuente/destino a veces son llamadas
entidades externas porque ellas están fuera del sistema. Una vez procesado, datos o
información salen del sistema y van a algún otro lugar. Puesto que las fuentes y destino
están fuera del sistema, que nosotros estamos estudiando, hay muchas características de
fuentes y destinos que nos son de interés para nosotros. En particular, nosotros no
consideramos lo siguiente:

 Interacciones que ocurren entre las fuentes y archivo de datos.

 Como una fuente o destino hace con la información o cómo opera (es decir, una
fuente o destino es una "caja negra").

 Cómo controlar o rediseñar una fuente o salida subsecuentemente desde la


perspectiva del sistema que nosotros estamos estudiando, los datos que un destino
recibe y a menudo qué datos fijos proporcionan una fuente.

 Cómo proporcionar fuentes y destinos de acceso directo a los datos guardados,


como agentes externos, ellos no pueden acceder directamente o manipular datos
almacenados dentro del sistema; es decir, los procesos dentro del sistema deben
recibir o deben distribuir los datos entre el sistema y su ambiente.

Los símbolos para cada una de las convenciones de DFD, se presentan en la figura 5-1.
Para ambas convenciones, un flujo de datos es dibujado como una flecha. La flecha es
etiquetada con un nombre significante para el dato en movimiento; por ejemplo, el pedido
del cliente, recepción de ventas, o el sueldo. El nombre representa la agregación de todos
los elementos individuales del movimiento de datos como una parte de un paquete, que es,
todo el movimiento de los datos juntos al mismo tiempo. Un cuadrado es usado en ambas
convenciones para las fuente / destinos y tiene un nombre que declara lo que el agente
externo es, tales como, cliente, cajero, la oficina EPA, o un sistema de control de
inventario. El símbolo Gane & Sarson para un proceso es una rectángulo con esquinas
redondeadas; el cuál tiene una línea en el tope. La porción de arriba es usada para indicar el
número del proceso. Dentro de la porción de abajo está el nombre del proceso, tales como,
sueldo del gerente, calcular el pago de horas extras, etc. El símbolo de Gane & Sarson para
un dato de almacenamiento es un rectángulo que en el cual falta su lado vertical derecho.
Al extremo izquierdo está una caja pequeña numerada y dentro de la parte principal del
rectángulo está una etiqueta significante para los datos que se almacenarán, como los datos
del estudiante, transcripciones, o lista de clases.
Análisis y Diseño 128 Análisis
de Sistemas

Como se ha manifestado antes, fuentes / destinos siempre están fuera del sistema de
información y definen los límites del sistema. Los datos deben originarse fuera de un
sistema de uno o más fuentes y el sistema debe producir la información a uno o más
destinos (éstos son principios de sistemas abiertos, y casi cada sistema de información es un
ejemplo de un sistema abierto).

proceso

Archivo de datos

Fuente / destino

Flujo de datos

DeMarco & Yourdon Gane & Sarson

Figura 5-3. Símbolos para un DFD

Una fuente / destino podría consistir en lo siguiente:

 Otra organización o unidad de la organización que envían los datos para recibir la
información del sistema que usted están analizando (por ejemplo, un proveedor o
una sección académica - en cualquier caso, esta organización es externa al sistema
que usted está estudiando)

 Una persona dentro o fuera de la unidad del negocio soportado por el sistema que
usted está analizando y quien interactúa con el sistema (por ejemplo, un cliente u
oficina d préstamo)

 Otro sistema de información con el cual el sistema que usted está analizando
intercambia información.
Análisis y Diseño 129 Análisis
de Sistemas

Desarrollando un DFD: Un ejemplo

Para ilustrar como son usados los DFDs para el modelo lógico de flujo de datos en un
sistema de información, se presenta y se trabaja a través de un ejemplo. Considere un
sistema de pedidos de comida de Hamburguesas Hoosier. La vista de nivel más alto del
sistema, es un diagrama de contexto, se muestra en figura 5-2. Usted notará que este
diagrama de contexto contiene un solo proceso, ningún dato se guarda, cuatro datos fluyen,
y tres fuentes / destinos. El proceso se etiquetó "0", representa el sistema entero; todos los
diagramas de contexto tienen sólo un proceso etiquetado con "0." La fuente / destino
representa sus límites medioambientales. Puesto que los archivos de datos de sistema están
conceptualmente dentro de un proceso, ninguna archivo de datos aparece en un diagrama
del contexto.

CLIENTE COCINA

Pedido del
Cliente 0
Orden de
comida
Sistema de
Pedido de
Recibo
Comida

Reporte del
Gerencia

GERENCIA DEL
RESTAURANTE

Figura 5-4. Diagrama de contexto del sistema de pedidos de comida Hamburguesas


Hoosier

El siguiente paso para el análisis es pensar acerca de que procesos son representados por el
proceso simple en el diagrama de contexto. Come se puede ver el la figura 5-3, se tiene
identificado cuatro procesos separados, proporcionando mas detalle del sistema que
estamos estudiando. El proceso principal representa el proceso mayor del sistema y estas
funciones mayores corresponden a tales acciones como las siguientes:

1. Capturando datos desde diferentes archivos de datos (ejemplo Procesos 4.0)


2. Manteniendo los archivos de datos (ejemplo Procesos 2.0 y 3.0)
3. Produciendo y distribuyendo datos para diferentes destinos (Proceso 4.0)
4. Descripción del nivel más alto del funcionamiento de transformación de datos.
(ejemplo Proceso 1.0)

A menudo, estas funciones mayores corresponden a la selección de actividades en el


menú principal del sistema.
Análisis y Diseño 130 Análisis
de Sistemas

Nosotros vemos que el sistema empieza con una orden de un cliente, como era el caso
en el diagrama del contexto. En el primer proceso, etiquetado “1.0” vemos que la orden
del cliente es procesado. El resultado son cuatro flujos o flujos de datos: (1) la orden de
comida es transmitida a la cocina (2) la orden del cliente es transformada en una lista de
producto vendido (3) la orden del cliente es transformada en un dato de inventario (4) el
proceso genera un recibo para el cliente.

Note que la fuente/destino son el mismo en el diagrama de contexto y en este diagrama:


el cliente, la cocina y el gerente del restaurante. Este diagrama es llamado diagrama de
nivel – 0 como este representa el proceso individual primario en el nivel más alto
posible.

CLIENTE COCINA

Pedido del
1.0 Orden de
Cliente comida
Recibo y
transformación
Recibo de la orden de
comida del
cliente

2.0 Producto Dato de


3.0
vendido inventario
Actualización del Actualización del
archivo del archivo de
producto vendido inventario

Datos de producto Inventario de


vendido arreglado datos arreglado

D1 Archivo de
D2 Archivo Inventario
producto vendido

Inventario diario
4.0 Reducción de cantidades

Cantidad diaria Reporte


de productos producidos por el
vendidos gerente Reporte de
gerencia GERENCIA DEL
RESTAURANTE

Figura 5-5. Diagrama de nivel 0


Análisis y Diseño 131 Análisis
de Sistemas

Reglas para los diagramas de flujo de datos

Existe un conjunto de reglas que usted puede seguir para la construcción de un DFD. Las
reglas para los DFDs son listadas en la tabla 5-5. La figura 5-6 ilustra las formas incorrectas
y correctas para la aplicación de los DFDs.

Además de las reglas de la tabla 5-1, hay dos pautas de DFD que se aplican la mayor parte
del tiempo:

 Las entradas a un proceso son diferentes de las salidas de ese proceso. La razón es
que los procesos, tienen un propósito, típicamente transforman las entradas en los
salidas, en lugar de que los datos pasen a través de una simple manipulación. Lo que
puede pasar es que la misma entrada va en y fuera de un proceso pero el proceso
también produce otro nuevo flujo de lo datos que es el resultado de manipular las
entradas.

 Los objetos en un DFD tienen nombres únicos. Cada proceso tiene un nombre.
único No hay ninguna razón para tener los procesos con el mismo nombre. Para
guardar un DFD no desordenado, sin embargo, usted puede repetir los archivos de
datos y las fuentes / destino. Cuando dos flechas tienen los mismos nombre de flujo
de dato, usted debe tener el cuidado que estos flujos sean exactamente los mismos.
Es fácil de re usar los mismos nombres de flujo de dato cuando dos paquetes de
datos son casi el mismo, pero no idénticos. Un nombre de flujo de dato representa
un juego específico de datos, y otro flujo de datos que tiene incluso uno más o uno
menos de piezas de datos debe darse un nombre diferentes único.

Tabla 5-5 Reglas para los DFDs

Proceso Flujo de Datos


A. Ningún proceso puede tener J. Un flujo de datos tiene sólo una
solamente salida. Si un objeto tiene dirección de flujo entre los
solo salidas, entonces debe ser una símbolos. Puede fluir en ambas
fuente. direcciones entre un proceso y los
B. Ningún proceso puede tener sólo archivos de datos para mostrar una
entradas. Si un objeto tiene sólo lectura antes de una actualización.
entradas, entonces debe ser un El último es usualmente indicado,
destino. sin embargo, por dos flechas
C. Un proceso tiene una etiqueta de separadas puesto que éstos pasan en
frase de verbo. momentos diferentes
K. Una ramificación en un flujo de
Archivo de Datos datos que significa que exactamente
el mismo dato va de una
D. Los datos no pueden mover localización común a dos o mas
directamente desde un archivo de procesos diferentes, los archivos
datos a otro archivo de datos. Los datos, o fuente / destinos (esto
datos deben ser movidos por un normalmente indica copias
Análisis y Diseño 132 Análisis
de Sistemas

proceso. diferentes de los mismos datos que


hacen a las localizaciones
E. Los datos no pueden moverse diferentes)
directamente de una fuente externa L. Un acoplamiento en un flujo de
a un archivo de datos. Los datos datos significa que exactamente el
deben ser movidos por un proceso mismo viene de cualquiera de dos o
que recibe los datos desde la fuente más procesos diferentes, archivos
y colocar los datos dentro del datos, o fuentes / destinos a una
archivo de datos. situación común.

F. Los datos no pueden moverse M. Un flujo de datos no puede regresar


directamente a una salida externa al mismo proceso que sale. Debe
desde un archivo del dato. Los haber otro proceso que se ocupe del
datos deben ser movidos por un flujo de datos, producir algunos
proceso. otros flujos de datos, y retorne al
flujo de dato original al principio del
G. Un archivo de datos tiene un tiene proceso.
una etiqueta de frase como
nombre. N. Un flujo de datos para un archivo
de datos significa actualización
Fuente / Destino (eliminar o cambiar)

H. Los datos no pueden moverse O. Un flujo de datos desde un archivo


directamente de una fuente a un de datos significa recuperar o usar.
destino. Debe moverse por un
proceso, si los datos son de interés P. Un flujo de datos tiene una etiqueta
a nuestro sistema. Por otra parte, el de nombre.
flujo de los datos no se muestra en
el DFD.

I. Una fuente / destino tiene una


etiqueta de frase como nombre.

En el ejemplo anterior del sistema de pedidos de comida de Hamburguesa Hossier,


nosotros empezamos con un nivel alto como es el diagrama de contexto. Al pensar más
sobre el sistema, nosotros vimos que el sistema más grande consistía de cuatro procesos. El
hecho de ir desde un solo sistema a otro proceso se llama (funcional) la descomposición. La
descomposición funcional es un proceso iterativo de ruptura de la descripción o
perspectiva de un sistema en el detalle más fino. Este proceso crea un conjunto de juego de
gráficos jerárquicamente relacionados en el cuál un proceso en un gráfico dado se explica
en detalle mayor en otro gráfico. Para el sistema de Hamburguesa Hoosier, nosotros
descompusimos el sistema más general en cuatro procesos. Cada uno de estos procesos (o
subsistemas) también es candidato para la descomposición. Cada proceso puede consistir de
varios subprocesos. Cada subproceso también puede descomponerse en unidades más
pequeñas. La descomposición continúa hasta que usted haya alcanzado el punto más bajo
Análisis y Diseño 133 Análisis
de Sistemas

donde ningún subproceso puede descomponerse lógicamente en otros. El nivel más bajo de
DFDs se llama un DFD primitivo.

Regla Incorrecto Correcto

A.

B.

D.

E.

F.

H.

J.
Análisis y Diseño 134 Análisis
de Sistemas

K.
A A

B
A

L.
A A

B A

M.
A B

A A
A

Figura 5-6 Métodos incorrecto y correcto para graficar un DFD

Continuando con el sistema de pedido de comida de Hamburguesa de Hoosier para ver


como un nivel 0 del DFD puede ser descompuesto mas se sigue:

El primer proceso en la Figura 5-7, es llamado Recibo y Transformación de la Orden de


Comida del Cliente, la transformación verbal del pedido de la comida de un cliente (por
ejemplo, "Déme dos hamburguesas con queso, una orden pequeña de frituras, y un refresco
de naranja") en cuatro diferentes salidas.

El proceso 1.0 es un proceso candidato para la descomposición. Piense sobre todas las
tareas diferentes que el proceso 1.0 tiene que realizar:

(1) Reciba un pedido del cliente.


(2) Transforme el pedido de entrado en una forma significante para la cocina.
(3) El pedido en un recibo impreso para el cliente.
(4) Transforme el pedido en unos datos de producto vendido.
(5) Transforme el pedido en datos de inventario.

Estas cinco funciones, lógicamente separadas, ocurren en el Proceso 1.0. Nosotros podemos
representar la descomposición de Proceso 1.0 como otro DFD, como en la figura 5-7.
Análisis y Diseño 135 Análisis
de Sistemas

1.1 1.3 Comida del


Pedido del Pedido del Cliente
cliente Recibo del cliente Transformación
Pedido del de l pedio para
Cliente ser preparado
en la cocina 1.5
Pedido del Dato de
cliente Generación de inventario
Pedido del Decremento de
cliente Pedido del cliente Inventario

1.2 1.4
Generación del Generación del Dato del producto vendido
recibo del incremento del
cliente producto
vendido

Recibo

Figura 5-7 Diagrama del nivel 1 desde el nivel 0

5.4 Modelo lógico

El modelo lógica involucra la representación de la estructura interior y funcional de los


procesos representados en los diagramas de flujos de datos. Estos procesos aparecen en un
DFD como cajas negras más pequeñas y podemos señalar solamente sus nombres y lo que
ellos hacen. Sin embargo, la estructura y funcionalidad de los procesos de un sistema son
un elemento importante de cualquier sistema de información. Deben describirse los
procesos claramente antes de que ellos puedan traducirse en un idioma de programación.
En este apartado, nosotros enfocaremos técnicas que usted puede utilizar durante el
modelado lógica dentro de los procesos, es decir, transformación de datos a información y
decisiones. En la fase del análisis, el modelo o lógico será completado y razonablemente
detallado, pero también será genérico, es decir no reflejará la estructura o sintaxis de un
lenguaje de programación en particular.

Modelando la lógica de un sistema

El modelo lógica de un sistema es parte de la estructuración de requerimientos, así como


estaba representando el sistema con los diagramas de flujo de datos. Aquí nuestro enfoque
está en los procesos dibujados en los diagramas de flujo de datos y el contenido lógico
dentro de cada uno. Usted también puede usar el modelo lógica para indicar cuando un
proceso ocurre en un DFD (por ejemplo, cuando un proceso extrae cierto flujo de dato de
un archivo de datos). Así como nosotros usamos el modelo lógico para representar la lógica
contenida en los procesos de un diagrama de flujo de datos, nosotros usaremos el modelo
de datos para representar los volúmenes y estructura de los datos de un diagrama de flujo de
datos y archivo de datos.
Análisis y Diseño 136 Análisis
de Sistemas

5.4.1 DERIVABLES Y RESULTADOS

Los derivables que resultan de la documentación de los procesos lógicos de un sistema son:

 Representación del Inglés Estructurado


 Representación de tablas de decisión
 Representación de árbol de decisión

Modelo lógico con el Inglés Estructurado

El ingles estructurado es una forma del inglés modificado que es usado para especificar el
contenido de los procesos en un DFD. Este incluye verbos como leer, escribir, imprimir,
unir, ordenar, adicionar, restar, multiplicar, y dividir. En el ingles estructurado también se
usa frases para describir la estructura de datos, tales como nombre del patrón y dirección
del patrón. El inglés estructurado no utiliza adjetivos y adverbios.

Es posible usar inglés estructurado para representar los tres procesos típicos de la
programación estructurada: la secuencial, condicionales y repetitivas. La secuencial no
requiere de ninguna estructura especial pero puede representarse con una declaración
secuencial que sigue a otra. Pueden representarse las declaraciones condicionales con una
estructura como lo siguiente:

BEGIN IF
IF Cantidad – en – stock es menor que la cantidad – mínima – pedido
THEN GENERATE nuevo pedido
ELSE DO nada
END IF

Otro tipo de declaraciones condicionales es el case donde existen muchas acciones


diferentes que un programa puede seguir, pero solamente uno es escogido. Una case puede
ser representado como:
Análisis y Diseño 137 Análisis
de Sistemas

READ Cantidad - en - stock


SELECT CASE
CASE 1 (Cantidad - en - stock es mayor que la cantidad – mínima – pedido)
DO nada
CASE 2 (Cantidad - en - stock es igual que la cantidad – mínima – pedido)
DO nada
CASE 3 (Cantidad - en - stock es menor que la cantidad – mínima – pedido)
GENERATE nuevo pedido
CASE 4 (stock agotado)
INITIATE emergencia de rutina de nuevo pedido
END CASE

Las repetitivas pueden tomarse de dos formas: Do – Until or Do – While.


El ciclo Do – Until es representado como:

DO
READ Registros de inventario
BEGIN IF
IF (Cantidad - en - stock es menor que la cantidad – mínima – pedido)
THEN GENERATE nuevo pedido
ELSE DO nada
END IF
UNTIL Fin – de – archivo

Un ciclo Do –While se representa como:

READ registro de inventario


WHILE NOT Fin – de – archivo
BEGIN IF
IF (Cantidad - en - stock es menor que la cantidad – mínima – pedido)
THEN GENERATE nueva orden
ELSE DO nada
END IF
END DO
Análisis y Diseño 138 Análisis
de Sistemas

Ejemplo

DFD actual para el sistema de control de inventario

Cuentas
STOCK
PROVEEDOR Facturas DISPONIBLE

1.0 2.0

Actualizar Actualizar
inventario inventario
adicionado utilizado
Pagos Facturas

Cantidad Cantidad
adicionada Utilizada
D1 INVENTARIO

Pedido

Nivel de
4.0 3.0 inventario

Generar Generar
pagos pedidos

Cantidad Mínima de
pedidos

Proceso 1.0: Actualizar inventario adicionado

DO
READ siguiente registro - ítem– factura
FIND igualar registro de inventario
ADD Cantidad – adicionada desde registro - ítem– factura para cantidad – en – stock en registro – inventario
UNTIL fin –de- archivo

Proceso 2.0 Actualizar inventario utilizado

READ siguiente registro- ítem - stock


FIND igualar registro de inventario
SUBTRACT cantidad – usada en registro- ítem - stock desde cantidad – en – stock en Registro – inventario
UNTIL fin – de –archivo
Proceso 3.0 Generar pedidos

DO
READ siguiente registro de inventario
BEGIN IF
IF cantidad – en –stock es menor que cantidad – mínima- pedido
THEN GENERATE Pedido
END IF
UNTIL Fin – de – archivo
Análisis y Diseño 139 Análisis
de Sistemas

Proceso 4.0 Generar Pagos

READ Fecha – actual


DO
SORT Registro de factura por fecha
READ siguiente registro de factura
BEGIN IF
IF fecha es 30 días o más que fecha – actual
THEN GENERATE pago
END IF
UNTIL fin – de - archivo

Tablas de decisión

Una tabla de decisión es un diagrama de procesos lógicos donde la lógica es completada


razonablemente, se representan todas las posibles opciones y las condiciones de las que las
opciones dependen en forma tabular, como se ilustra en la tabla de decisión de la figura
siguiente:

Condición / Reglas
Combinaciones de acción 1 2 3 4 5 6
Condición Tipo de empleado S H S H S H
Horas trabajadas <40 <40 40 40 >40 >40

Pago del salario Base X X X


Acción Calcular sueldo de cada hora X X X
Calcular horas extras X
Producir reporte de inasistencia X

La tabla de decisión modela la lógica de un sistema de pagos. Hay tres partes en la tabla:
condición, acción y reglas. La condición contiene varias condiciones que se aplica en la
situación en que la tabla es modelada. En la figura hay dos condiciones por tipo de
empleados y horas trabajadas El tipo de empleado tiene dos valores “S”, el cual es puesto
para salarios, y “H”, el cual es puesto para horas. Las horas trabajadas tiene tres valores:
menor que 40, exactamente 40 y mayor que 40. Las acciones contienen todos los caminos
de acción que resulta de combinar valores de las condiciones. Hay cuatro caminos posibles
de acción en la tabla: Pago del salario base, calcular el sueldo de cada hora, calcular horas
extras, Producir reporte de inasistencia. Usted puede ver que no todas las acciones son
activadas por todas las combinaciones de las condiciones En cambio, combinaciones
específicas activan acciones específicas. La parte de la tabla que enlaza condiciones a
acciones es la sección que contiene las reglas.

Para leer las reglas, primero se lee los valores de la condiciones especificadas en la primera
columna: Tipo de empleado es “S”, o salario, y horas trabajadas es menor que 40. Cuando
ambas de estas condiciones ocurren el sistema de pagos es para pagar el salario base.
Análisis y Diseño 140 Análisis
de Sistemas

Construcción de tablas de decisión

Para construir tablas de decisión, nosotros tenemos actualmente un conjunto de


procedimientos básicos, como sigue:

1. Nombrar las condiciones y los valores de las condiciones que pueden asumirse.
Determinar todas las condiciones que son relevantes en su problema, y entonces
determinar todos los valores de cada condición que pueda tomar.

2. Nombrar todas las posibles acciones que pueda ocurrir. El propósito de crear tablas
de decisión es determinar el camino apropiado de acción dada par un conjunto de
condiciones.

3. Listar todas las posibles reglas. Cuando usted crea una tabla de decisión debe crear
un exhaustivo conjunto de reglas. Cada combinación posible de condiciones puede
ser representada. Puede resultar que algunas de las reglas resulten ser redundantes o
no tengan ningún sentido, pero ninguna posibilidad deber ser pasada por alto. Para
determinar el número de reglas, multiplique el número de valores por cada
condición por el número de valores de cada otra condición.

En el ejemplo anterior la condición tipo de empleado tiene dos valore, S y H, la


condición horas trabajada tiene 3 valores, <40, = 40, >40, entonces el número de
reglas será 2  3  6 .

4. Definir las acciones para cada regla. Ahora todas las posibles reglas son
identificadas, se debe proporcionar una acción para cada regla. En nuestro ejemplo,
nosotros éramos capaces para deducir lo que cada acción debe ser y si todas las
acciones realizadas tienen sentido. Si una acción no tiene sentido, usted puede crear
un fila "imposible", la acción en la tabla para guardar huellas de acciones
imposibles. Si usted no puede decir lo que el sistema debe hacer en esa situación,
los signos de interrogación son colocados en ese lugar.

5. Simplificar la tabla de decisión. Haga la tabla de decisión tan simple como sea
posible quitando cualquier regla con las acciones imposibles. Consulte a los
usuarios, en las reglas dónde las acciones del sistema no están claras y / o deciden
en una acción o quite la regla.

Ejemplo

Tabla de decisión completa para el sistema de inventario de Hamburguesas Hoosier


Análisis y Diseño 141 Análisis
de Sistemas

Condiciones/ Reglas
Combinaciones de Acción 1 2 3 4 5 6 7 8 9 10 11 12
Tipo de Ítem P N P N P N P N P N P N
Tiempo en semanas D D W W D D W W D D W W
Estación de año A A A A S S S S H H H H

Pedido diario vigente X X X


Pedido semanal vigente X X X
Cantidad mínima de pedido X X X X X X
Reducción en fiestas X X
Reducción en verano X X

Tipo de Ítem: Tiempo en semanas: Estación del año:

P = temporal D = Día de la semana A = año académico


N = no Temporal W = Fin de semana S = verano
H = Fiestas

MODELO LÓGICO CON ÁRBOL DE DECISIÓN

Un árbol de decisión es una técnica gráfica que describe una decisión o elección de una
situación, como una serie conectada de nodos y ramas. El árbol de decisión se inventó
primero como una técnica de la ciencia de administración para simplificar una opción
donde algunas de las necesidades de información no son conocidas con certeza. Confiando
en las probabilidades de ciertos eventos, un científico de administración, puede usar un
árbol de decisión para escoger el mejor curso de acción.

El árbol de decisión usado en la estructuración de requerimientos, tiene dos componentes


principales:

Puntos decisión, los cuales son representados por nodos, y acciones, representados por
elipses. La figura 5-8 muestra un árbol de decisión genérico. Para leer un árbol de decisión,
usted empieza en el nodo raíz. Cada nodo es numerado, y cada número corresponde a unas
alternativas; la alternativa se escribe en una leyenda en el diagrama. Cada salida de ruta
(camino), a un nodo corresponde a una de las opciones para esa alternativa. De cada nodo,
hay por lo menos dos caminos que conduce al siguiente paso, que es cualquiera punto de
decisión o una acción. Finalmente, se listan las todas las acciones posibles en la parte
derecha del diagrama, en los nodos de la hoja. Cada regla es representada para rastrear una
serie de caminos desde el nodo raíz, abajo un camino para el próximo nodo, y así
sucesivamente, hasta que una acción es alcanzada.
Análisis y Diseño 142 Análisis
de Sistemas

Domingo Dormir dos horas mas

Si 2 Día de trabajo

Tiempo de levantarse
1

Sábado
No

Dormir una hora mas

Leyenda:
1) ¿Tomar sol?
Remóntese a dormir
2) ¿Qué día es?

Figura 5-8

Por ejemplo si se desea realizar el modelo lógico para un sistema de planillas. Existen por
lo menos, dos maneras de representar esta información como un árbol de decisión. El
primero es la muestra en figura 5-9. Aquí todas las opciones se limitan a dos resultados, sí
o no.

SI
Pago del salario básico
1

NO SI
Pago de sueldo por hora, el
2 ausencia de informe

NO SI
Pago de sueldo por hora
3

Pago de sueldo por hora;


Leyenda NO Pago de horas extras
1) ¿Asalariado?
2) ¿Horas trabajadas <40?
3) ¿Horas trabajadas =40

Figura 5-9
Análisis y Diseño 143 Análisis
de Sistemas

Otra forma de representar este árbol de decisión con dos condiciones y en una de ellas con
tres condiciones es:

Asalariado Pago del salario básico


1

Horas < 40 Pago de sueldo por hora, el


2 ausencia de informe
= 40

Pago de sueldo por hora


> 40

Leyenda:
Pago de sueldo por hora;
1) Tipo de empleado Pago de horas extras
2) Horas trabajadas

Figura 5-10

CRITERIOS PARA DECIDIR ENTRE EL INGLÉS ESTRUCTURADO,


TABLAS DE DECISIÓN Y CARBOLES DE DECISIÓN

Criterios para decidir entre el Ingles Estructurado, Tablas de Decisión y Árbol de


Decisión
Criterio Inglés Tablas de Árbol de
Estructurado Decisión Decisión
Determinar condiciones y Segundo Mejor Tercero Mejor Mejor
acciones
Transformación de Mejor Tercero Mejor Mejor
condiciones y acciones
entre secuencias
Verificando consistencia e Tercero Mejor Mejor Mejor
integridad

Figura 5-11

La primera tarea es determinar las condiciones correctas y acciones de una descripción del
problema, mucho de los analistas enfrentan la misma situación al definir condiciones y
Análisis y Diseño 144 Análisis
de Sistemas

acciones después de una entrevista con el usuario. El estudio encontró que los árboles de
decisión eran mejores técnicas para apoyar este proceso cuando ellos naturalmente
separaban condiciones y acciones, realizando la lógica de las reglas de decisión de manera
más clara. Aunque Inglés Estructuró no separa condiciones y acciones, fue considerado la
segunda técnica para esta tarea. Las tablas de decisión eran la peor técnica. La segunda
tarea es convertir las condiciones y acciones a declaraciones secuenciales, similar o lo que
un analista hace al convertir las condiciones declaradas y acciones a la secuencia de pseudo
código o a un idioma de programación.

MODELO DE DATOS CONCEPTUAL

Diagrama Entidad Relación

El diagrama entidad - relación es un modelo de red que describe la distribución de datos


almacenados en un sistema.

La diferencia principal con el DFD, es que está orientado a las funciones del sistema, es que
el modelo ER está orientado a los datos.

Una entidad puede ser una persona, lugar, cosa o evento cuya información es necesaria para
el sistema.

Una relación es la interacción entre las entidades y se representa con una línea que conecta
las entidades asociadas.

Cliente Productos

En este ejemplo, el diagrama se lee así:

Cliente adquiere producto y producto es comprado por cliente.

Sin embargo, es necesario agregar a este diagrama la cardinalidad. La cardinalidad explica


la forma exacta como se relacionan las entidades:

CARDINALIDAD SE LEE REPRESENTACIÓN


1:1 Uno a uno
1:M Uno a muchos
1:0 Uno o ninguno
M:1 Muchos a uno
M:M Muchos a muchos
M:0 Muchos a ninguno
Análisis y Diseño 145 Análisis
de Sistemas

Ejemplo de un sistema de ventas

hace
Cliente Pedido

es hecho por

es parte de contiene

Productos
es hecho realiza
por

ampara genera

cubre
Pago Factura

es liquidado por

Un ejemplo del modelo conceptual para Hamburguesas Hoosier

El diagrama de flujo de datos y la tabla de decisión (representado en la figura 5-11)


describe los requerimientos para un nuevo sistema. El propósito del nuevo sistema es
monitorear y brindar reportes de cambios en los niveles de inventario de materia prima y
para los problemas de pedidos de materiales y pagos a proveedores. La entidad central para
este sistema sería el ÍTEM DE INVENTARIO, correspondiente al archivo D1 en la figura
5-11.

Los cambios en los niveles de inventario son debido a dos tipos de transacciones:

 Recepción den nuevos ítems desde los proveedores.


 Consumo de ítems desde la venta de productos.

El inventario es adicionado en la recepción de una nueva materia prima, para el cual


Hamburguesas Dossier recibe un proveedor FACTURA (ver Proceso 1.0 en la
figura 5-11). Cada FACTURA indica que el proveedor tiene enviado una cantidad
específica de uno o más ITEM DE FACTURA, el cual corresponde a ITEMS DE
INVENTARIO de Hoosier. EL inventario es usado cuando se genera el pedido del cliente y
pago de PRODUCTOS.

Así el tiempo real del proceso del pedio del cliente es separado del sistema de control de
inventario, una fuente, STOCK DISPONIBLE en la figura 5-11, representado como el flujo
de datos del proceso de pedido para el sistema de control de inventario. Finalmente, los
Análisis y Diseño 146 Análisis
de Sistemas

PRODUCTOS de comida están hechos de varios ITEMS DE INVENTARIO. Hoosier


mantiene una RECETA para indicar como muchos de cada ITEM DE INVENTARIO va
dentro de la realización de un producto. Desde este análisis tenemos identificados las
entidades, el diagrama entidad relación se muestra en la figura 5-12.

Cuentas
factura STOCK
DISPONIBLE
PROVEEDOR

2.0
1.0
Adicionando Usando
Inventario inventario
Actualizado actualizado

pagos factura pedido Cantidad Cantidades


adicionada Usadas

D1 Archivo de
Inventario

Niveles de
Inventario Niveles de Respuesta
3.0 Inventario 5.0 consulta

Generando Consultas Consulta


pedidos Cantidad niveles de
inventario
mínima
de pedido
Demanda

GERENTE
4.0

Generando
pagos

Figura 5-11
Niveles de
Inventario
Análisis y Diseño 147 Análisis
de Sistemas

El siguiente esquema deberá identificar las entidades, atributos y cardinalidades para


modelo E-R de Hamburguesas Hoosier:

EJERCICIOS PROPUESTOS

1. Escriba por lo menos tres preguntas que usted podría usar en una encuesta que se
enviaría a los usuarios de un paquete de procesador de texto para desarrollar las
ideas para la próxima versión del paquete. Pruebe estas preguntas pidiéndole a un
amigo que responda; luego entrevístelo para determinar, si ella o él, no han
entendido cualquiera de sus preguntas y, en ese caso, vuelva a escribir las preguntas
para que sean entendidas.

2. Una entrevista se presta fácilmente al sondear preguntar para las encuestas, o


preguntas en diferentes encuestas que dependen de la respuesta proporcionado por
el entrevistado. Aunque no es imposible, el sondeo y las preguntas alternativas
pueden manejarse en un cuestionario. Discuta cómo usted pude incluir sondeo o un
conjunto alternativos de preguntas en una encuesta.

3. Uno de los problemas potenciales para recoger los requisitos de información


observando a los usuarios del sistema, mencionado en el capítulo, es que las
Análisis y Diseño 148 Análisis
de Sistemas

personas pueden cambiar su conducta cuando son observadas. ¿Qué podría hacer
para superar este factor que ayude determinar los requisitos de información con
precisión?

4. Refiérase a la siguiente figura qué contiene el diagrama de contexto y el nivel- 0


de un DFD, para un sistema de registro de clase universitario. Identifique y explique
violaciones potenciales de reglas y modifique el diagrama.

Horario de Clases
ESTUDIANTE

Requisito de Curso
0

Sistema
de
Lista de Cursos Posibles Clases
Registro
de clases
DEPARTAMENTO
Horario de Clases
D1 Lista de
Clases

DIAGRAMA DE CONTEXTO

Requisito de Curso
1
3
Formulario de Recepción Horario de Clases
estudiante de Verificar
Requisito Disponibilidad Para el Estudiante
de Curso
Horario de Clases

Requisito de Curso

Posible de Curso

Lista de Curso
2
Formulario de
Departamento Recibir D2 Posibles
lista de Clases
Curso

NIVEL – 0

5. Considere DFD de la siguiente figura. Liste tres errores en este diagrama.


Análisis y Diseño 149 Análisis
de Sistemas

DF2 1.0
E1
DF5 P2

DS1
DF1
DF6
DF3

DF4
2.0

E2 DF2
P1

6. Realizar la descomposición mediante DFD del siguiente caso:

GESTIÓN DE AGENCIA DE SEGUROS

Se debe desarrollar un sistema que gestione una agencia de seguros.


Dicho sistema tratará las peticiones de nuevos seguros, las actualizaciones de los datos
de los clientes y los contratos, las renovaciones de contratos y la información sobre la
utilización de los seguros por parte de los clientes.

El funcionamiento del sistema será el siguiente:

Cuando la empresa de seguros recibe una petición de una persona interesada en


suscribir un seguro a través de una agencia autorizada de dicha compañía, un operador
introducirá en el sistema los datos suministrados por la agencia, tanto los del cliente
(nombre y dirección) como los del seguro (número de seguro, tarifa, estado del seguro
“solicitado”, tipo de seguro y número de la agencia).Si la petición es cursada por un
agente de seguros, el campo número de la agencia quedaría vacío y se introducirá en su
lugar el número del agente que ha cursado la petición.
Cada semana el sistema producirá un informe con los datos del seguro solicitado par a
cada petición de seguro, con el objeto de que sean estudiados por los técnicos de la
compañía. Las conclusiones del departamento técnico actualizarán el sistema. Si no es
acepta la petición, el estado del seguro pasa a “no aceptado” y una semana después se
borran los datos de la petición del sistema. Si se acepta la petición, el estado del seguro
pasa a “activo” y se introducen en el sistema nuevos datos relativos al seguro (fecha de
inicio y de finalización).
Si hay un cambio en los datos del cliente, por ejemplo, un cambio de dirección, el
cliente se lo comunicaría directamente a la compañía de seguros y se introduciría en el
Análisis y Diseño 150 Análisis
de Sistemas

sistema. Si hay cambio en los datos del seguro, por ejemplo, un cambio en la tarifa por
impuestos, el departamento económico lo introduciría en el sistema.
Unos días antes de la fecha de finalización del contrato el sistema produciría un informe
con los datos del seguro que se hará llegar al cliente para que indique si lo quiere
renovar o no. En el caso de que el cliente renueve el contrato, el departamento técnico
introduciría las fechas de inicio y fin del contrato renovado. En el caso de que no lo
renueve, el estado del seguro pasa a “no renovado” y una semana después se borran los
datos del seguro del sistema.
En cualquier momento el cliente puede tener que utilizar el seguro, en cuyo caso el
departamento técnico actualizará el campo referente al número de veces que ha sido
utilizado. Después de que la ejecución haya sido realizada, el departamento económico
introducirá el importe de dicha actuación, que se suma al importe total gastado en dicho
seguro. Y el sistema producirá un informe con los datos del seguro que será entregado
al departamento económico.

REFERENCIAS BIBLIOGRAFICAS
(1) Jeffrey A. Hoffer – Joel F. George – Joseph S. Valacich, MODERN SYSTEMS ANÁLISIS & DESIGN, United Status of
American, De. Addison Wesley Longman, 1999.