virtual.usalesiana.edu.bovirtual.usalesiana.edu.bo/.../dossier/22011/880.docx · web viewnosotros...

Identificación del Proyecto y

Selección

Iniciación del Proyecto y Planificación

Análisis

Diseño Lógico

Diseño Físico

Implementación

Mantenimiento

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

ANÁLISIS

5.1 INTRODUCCIÓN

_

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

Determinación de requerimientos Estructuración de requerimientos Generación de alternativas y solución

2

Estructuración de Requerimientos

1

Determinación de Requerimientos

3

Generación y Selección de Alternativas


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?

Archivo del Proyecto

Las notas de la entrevista, los resultados del estudio Requerimientos

Planes del SI, Planes del Análisis, Requerimientos del servicio del sistema, Justificación del proyecto

Nuevas alternativas de la descripción del sistema

Descripción actual y alternativas del nuevoSistema

Recomendaciones estratégicas para reemplazar el nuevo sistema


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.


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.


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


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.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.

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.

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: Oficina, sala de conferencia o número de

teléfono.

Datos de la cita:Fecha Inicial:Fecha Final:

Objetivos:Qué datos para recopilarEn que beneficia el acuerdoQue áreas para explicar

Notificaciones:Fondo / la experiencia de la entrevistaOpiniones conocidas de la entrevista

Agenda:IntroducciónFondo del ProyectoVisión de la entrevista

Tópicos a se cubiertosPermiso para grabar el registro

Tópico 1 PreguntasTópico 2 Preguntas...Resumen de los puntos principalesPreguntas de la entrevistaCierre

Tiempo aproximado:1 minuto2 minutos

1 minuto

5 minutos7 minutos

2 minutos5 minutos1 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)

Entrevistado: Fecha:

Preguntas: Notas:


Pregunta 1:

¿Usted ha usado las ventas actuales que rastrean el sistema? En ese caso, ¿que a menudo?

Respuesta:

Si, yo pido un informe semanalmente de mi línea del producto.

Observaciones:

Parecía ansioso – puede haber terminado – estimando uso de frecuencia

Pregunta 2:

¿Qué es lo mínimo que le gusta de este sistema?

Respuesta:

Las ventas son mostradas en unidades, no 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.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. Frecuentementeb. A vecesc. Escasamented. 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:

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.

Tabla 5-3Función Nombre del proceso

Desarrollo Manejo de índicesDiseño de control acústicoDesarrollo de comunicación avanzadas


Diseño de componentes de cableGerencia de confiabilidadObjetivo de costoPrueba de diseñoRevisión de diseño y materialesRevisión de documentosEspecificación del diseño a alto nivelDiseño industrialCoordinación entre divisionesDiseño lógico y verificaciónCalificación de componentesDiseño del sistema de energíaGerencia del productoDivulgación del productoLanzamientoDiseño del producto a nivel del sistemaConfiabilidad y utilidad del sistemaRequerimientos del sistemaDiseño de instrumentos Diseño interactivo de sistemas para el usuarioAnálisis de la competenciaOperación de ingeniería Desarrollo de la informaciónPlaneación de interconexiónDesarrollo de interconexión de productosInstrumento de diseño físicoDiseño de sistemasGerencia de cambio en ingenieríaDesarrollo de productoControl del desarrollo del procesoDesarrollo de instrumentosControl del desarrollo del procesoDesarrollo electrónicoRequerimiento de la fase 0

Distribución RecepciónEmbarqueAlmacenamientoServicio de campo y apoyoTeleprocesamiento y controlDespacho de partesVehículo de fuerza motrizMercaderías aseguradas y rescatadasTransporteRecibos de producciónDesembolsosManejo de inventariosManejo de inventario físico


Contabilidad financiera Control de libro mayorControl financieroNóminaImpuestosPrecios de transferenciasCuentas por cobrarContabilidad con base en acumulacionesContabilidad de ingresosCuentas por pagarControl efectivoContabilidad de gastos por empleadosControl de activos fijosDistribución de trabajoContabilidad de costosAplicación financieraActivos fijos y asignaciónContabilidad y facturación entre compañíasControl de inventarios Apoyo de gestionesControl financiero

Planeación financiera Control de asignaciónControl de presupuestoEstimación de costosPlaneación financieraPrecios de transferenciasControl de inventarioPlaneación comercialGerencias de contratosPerspectiva financiera

Sistema de Información Metodología para el desarrollo de aplicacionesControles para administración de sistemasEvaluación a nivel de servicios

Control de producción Proceso de consignación Manejo de servicios y pedidos del clienteInvolucramiento inicial de manufactura y lanzamiento de productosEjecución de control efectivoApoyo de campo de partesPlaneación y pedidos de partesGerencia de planeación y programaciónGerencia de rendimiento de los volúmenes en planta de la empresaPartes sensibles a la locaciónDirección de sistema de trabajos en procesoDistribución


Proyección de inventarioPlaneación de nuevos productosPrecisión de trabajos en proceso Compromiso con el plan baseRegistro del proceso de manufactura

Compras Modificación y cancelaciónAceleración Facturas y pagoElección de proveedoresCostoDespachoCalidadRelaciones con proveedoresContratosAdquisición de laboratoriosÓrdenes de no producciónPago a proveedoresTransferencia de procesos entre plantas

Personal BeneficiosCompensacionesRelaciones con empleadosEmpleoIgualdad de oportunidadesRecursos administrativosDesarrollo gerencialServicios médicosInvestigación de personalServicio de personalUbicaciónRegistros SugerenciasDesarrollo e investigación administrativaProgramas de personal Evaluación del personalGerencias de recursos

Programación Productos de sistema distribuidosCentro de programaciónDesarrollo de softwareIngeniería de softwareProductos para la producción de software

Calidad Calificación de nuevos productosCalidad de proveedor

Servicios en la locación Instalaciones para solicitudes de modificacionesMisceláneos Costo de la calidad para manufactura de cajas

Estimación de los costos de serviciosPlaneació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 responsabilidad

Actividad Área de responsabilidad

1. Reconozca la necesidad. Complete el análisis de ingreso anual. Prepare la solicitud del personal.

Jefe de área 9. Entreviste a los candidatos y revise los detalles del cargo.

Jefe

2. Evalué el presupuesto. En caso afirmativo, firme la papeleta para la solicitud de personal. En caso negativo, devuelva todo el paquete en carta de rechazo al jefe.

Contralor 10. Notifique al departamento de personal sobre los resultados de la entrevista.

Jefe

3. Realice investigación interna Departamento de personal 11. Si el candidato apto está disponible, haga una oferta de empleo. Sino lo está, inicie el proceso de contratación externa.

Departamento de personal

4. Si existe candidatos internos, entregue una lista a la gerencia. Si no, inicie el proceso de contratación externa.

Departamento de personal 12. Evalué la oferta de empleo y notifique al departamento de personal sobre la decisión del candidato

Candidato

5. Revise los documentos de los candidatos, y prepare una lista de los que van a entrevistarse.

Jefe 13. En caso afirmativo, notifique al jefe que el cargo ha sido ocupado. Si no lo ha sido, pase a la actividad 14.


6. Haga que los jefes de los candidatos revisen el cargo con los empleados y determinen que empleados están interesados en la posición.

Departamento de personal 14. ¿Hay otros candidatos aceptables? Sino los hay, inicie el proceso de contratación externa.

Departamento de Personal

7. Notifique al departamento de personal sobre los candidatos interesados en la posición.

Candidato 15. Haga que el nuevo jefe se ponga en contacto con el jefe actual del candidato, y disponga lo necesario par que el candidato se incorpore al trabajo.

Jefe

8. Organice una reunión entre jefes y candidatos.


Gerente Dpto. de Personal Candidato Contralor


Donde:

Iniciosi

no

si

no

no

A

no

si

si

si


.

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 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 avisosD96/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.

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 procesos1. Diagrama de Flujo de Contexto (DFD)2. DFDs del sistema físico actual 3. DFDs del sistema lógico actual4. 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.

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 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. 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).

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.

proceso

Archivo de datos

Fuente / destino

Flujo de datos

0

Sistema de Pedido de Comida

COCINACLIENTE

GERENCIA DEL RESTAURANTE

Pedido del Cliente

Recibo

Orden de comida

Reporte del Gerencia


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.

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.

COCINACLIENTE

Pedido del Cliente

Recibo

Orden de comida

Producto vendido

1.0

Recibo y transformación de la orden de comida del cliente Recibo y transformación de la orden de comida del cliente

2.0

Actualización del archivo del producto vendido

4.0

Reporte producidos por el gerente


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.

Figura 5-5. Diagrama de nivel 0

GERENCIA DEL RESTAURANTE

Inventario de datos arreglado

D1 Archivo de Inventario

Inventario diarioReducción de cantidades

Reporte de gerencia

D2 Archivo producto vendido

Datos de producto vendido arreglado

Cantidad diaria de productos

vendidos


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 DatosA. Ningún proceso puede tener

solamente salida. Si un objeto tiene solo salidas, entonces debe ser una fuente.

B. Ningún proceso puede tener sólo entradas. Si un objeto tiene sólo entradas, entonces debe ser un destino.

C. Un proceso tiene una etiqueta de frase de verbo.

Archivo de Datos

D. Los datos no pueden mover directamente desde un archivo de datos a otro archivo de datos. Los datos deben ser movidos por un

J. Un flujo de datos tiene sólo una dirección de flujo entre los símbolos. Puede fluir en ambas direcciones entre un proceso y los archivos de datos para mostrar una lectura antes de una actualización. El último es usualmente indicado, sin embargo, por dos flechas separadas puesto que éstos pasan en momentos diferentes

K. Una ramificación en un flujo de datos que significa que exactamente el mismo dato va de una localización común a dos o mas procesos diferentes, los archivos datos, o fuente / destinos (esto normalmente indica copias


proceso.

E. Los datos no pueden moverse directamente de una fuente externa a un archivo de datos. Los datos deben ser movidos por un proceso que recibe los datos desde la fuente y colocar los datos dentro del archivo de datos.

F. Los datos no pueden moverse directamente a una salida externa desde un archivo del dato. Los datos deben ser movidos por un proceso.

G. Un archivo de datos tiene un tiene una etiqueta de frase como nombre.

Fuente / Destino

H. Los datos no pueden moverse directamente de una fuente a un destino. Debe moverse por un proceso, si los datos son de interés a nuestro sistema. Por otra parte, el flujo de los datos no se muestra en el DFD.

I. Una fuente / destino tiene una etiqueta de frase como nombre.

diferentes de los mismos datos que hacen a las localizaciones diferentes)

L. Un acoplamiento en un flujo de datos significa que exactamente el mismo viene de cualquiera de dos o más procesos diferentes, archivos datos, o fuentes / destinos a una situación común.

M. Un flujo de datos no puede regresar al mismo proceso que sale. Debe haber otro proceso que se ocupe del flujo de datos, producir algunos otros flujos de datos, y retorne al flujo de dato original al principio del proceso.

N. Un flujo de datos para un archivo de datos significa actualización (eliminar o cambiar)

O. Un flujo de datos desde un archivo de datos significa recuperar o usar.

P. Un flujo de datos tiene una etiqueta de 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


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.


K.

L.

M.

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.

B

A A

A

A

B

A

A

A

A

A

B

C

A

1.1

Recibo del Pedido del Cliente

1.3

Transformación de l pedio para ser preparado en la cocina

1.5

Generación de Decremento de Inventario

1.2

Generación del recibo del cliente

1.4

Generación del incremento del producto vendido

Pedido del cliente Pedido del clienteComida del Cliente

Pedido del cliente

Pedido del clientePedido del cliente

Dato de inventario

Dato del 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.


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 – pedidoTHEN GENERATE nuevo pedidoELSE 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:


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:

DOREAD Registros de inventarioBEGIN IF

IF (Cantidad - en - stock es menor que la cantidad – mínima – pedido)THEN GENERATE nuevo pedidoELSE DO nada

END IF UNTIL Fin – de – archivo

Un ciclo Do –While se representa como:

READ registro de inventarioWHILE 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


Ejemplo

DFD actual para el sistema de control de inventario

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 – inventarioUNTIL fin –de- archivo

Proceso 2.0 Actualizar inventario utilizado

READ siguiente registro- ítem - stockFIND igualar registro de inventarioSUBTRACT cantidad – usada en registro- ítem - stock desde cantidad – en – stock en Registro – inventarioUNTIL 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 IFUNTIL Fin – de – archivo

1.0

Actualizar inventario adicionado

2.0

Actualizar inventario utilizado

3.0

Generar pedidos

4.0

Generar pagos

PROVEEDORSTOCK

DISPONIBLE

D1 INVENTARIO

Facturas

Pagos Facturas

Pedido

Cantidad adicionada

Cantidad Utilizada

Nivel de inventario

Cantidad Mínima de pedidos

Cuentas


Proceso 4.0 Generar Pagos

READ Fecha – actualDO 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 IFUNTIL 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:

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.

Condición

Acción

Condición / Combinaciones de acción

Reglas1 2 3 4 5 6

Tipo de empleado S H S H S HHoras trabajadas <40 <40 40 40 >40 >40

Pago del salario Base X X XCalcular sueldo de cada hora X X XCalcular horas extras XProducir reporte de inasistencia X


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


Condiciones/ Combinaciones de Acción

Reglas1 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 NTiempo en semanas D D W W D D W W D D W WEstación de año A A A A S S S S H H H H

Pedido diario vigente X X XPedido semanal vigente X X XCantidad mínima de pedido X X X X X XReducción en fiestas X XReducción en verano X X

Tipo de Ítem:

P = temporal N = no Temporal

Tiempo en semanas:

D = Día de la semanaW = Fin de semana

Estación del año:

A = año académicoS = veranoH = 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.

1

2

Dormir dos horas mas

Tiempo de levantarse

Dormir una hora mas

Remóntese a dormir

Domingo

Día de trabajo

Sábado

Si

No

Leyenda:¿Tomar sol?¿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.

Figura 5-9

1

2

3

Pago del salario básico

Pago de sueldo por hora, el ausencia de informe

Pago de sueldo por hora

Pago de sueldo por hora; Pago de horas extras

SI

SI

SI

NO

NO

NO Leyenda1) ¿Asalariado?2) ¿Horas trabajadas <40?3) ¿Horas trabajadas =40

1

2

Pago del salario básico

Pago de sueldo por hora, el ausencia de informe

Pago de sueldo por hora

Pago de sueldo por hora; Pago de horas extras

Asalariado

Horas < 40

= 40

> 40


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

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 Estructurado

Tablas de Decisión

Árbol de Decisión

Determinar condiciones y acciones

Segundo Mejor Tercero Mejor Mejor

Transformación de condiciones y acciones entre secuencias

Mejor Tercero Mejor Mejor

Verificando consistencia e integridad

Tercero Mejor Mejor Mejor

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

Leyenda:

1) Tipo de empleado2) Horas trabajadas


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.

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ÓN1:1 Uno a uno1:M Uno a muchos1:0 Uno o ningunoM:1 Muchos a unoM:M Muchos a muchosM:0 Muchos a ninguno

Cliente Productos

Cliente Pedido

Pago

Productos

Factura

es hecho por

hace

realizaes hecho por

cubre

es liquidado por

es parte de contiene

ampara genera


Ejemplo de un sistema de ventas

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

1.0AdicionandoInventario

Actualizado

2.0

Usando inventario actualizado

4.0

Generando pagos

3.0

Generando pedidos

5.0

Consulta niveles de inventario

PROVEEDOR

STOCKDISPONIBLE

GERENTE

D1 Archivo de Inventario

factura

pagos factura pedido Cantidad adicionada

Niveles de Inventario

Cantidad mínima de pedido


Consultas

Demanda

Respuesta consulta


Cuentas

Cantidades Usadas

Figura 5-11


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.


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

0

Sistema de Registro de clases

ESTUDIANTE

DEPARTAMENTO

D1 Lista de Clases

Horario de Clases

Posibles ClasesLista de Cursos

Requisito de Curso

Horario de Clases

3

Verificar Disponibilidad

1

Recepción de Requisito de Curso


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.

DIAGRAMA DE CONTEXTO

NIVEL – 0

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

2

Recibir lista de Curso

D2 Posibles Clases

Horario de Clases

Requisito de Curso

Requisito de Curso

Lista de Curso

Formulario de estudiante

Formulario de Departamento

Horario de Clases

Para el Estudiante

Posible de Curso

1.0

P2

2.0

P1

DF3

DS1

E1

E2

DF2

DF5

DF6

DF4

DF2

DF1


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


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.

virtual.usalesiana.edu.bovirtual.usalesiana.edu.bo/.../dossier/22011/880.docx · web viewnosotros...

Documents