viernes, 26 de septiembre de 2008

DFD (Data Flow Diagrams)

DFD Principles:

  • The general principle in Data Flow Diagramming is that a system can be decomposed into subsystems, and subsystems can be decomposed into lower level subsystems, and so on.
  • Each subsystem represents a process or activity in which data is processed. At the lowest level, processes can no longer be decomposed.
  • Each 'process' (and from now on, by 'process' we mean subsystem and activity) in a DFD has the characteristics of a system.
  • Just as a system must have input and output (if it is not dead), so a process must have input and output.
  • Data enters the system from the environment; data flows between processes within the system; and data is produced as output from the system.

Data Flow Diagrams show:

  • The processes within the system.
  • The data stores (files) supporting the system's operation.
  • The information flows within the system.
  • The system boundary.
  • Interactions with external entities.

DFD Notations:

  • Processes, in other methodologies, may be called 'Activities', 'Actions', 'Procedures', 'Subsystems' etc.They may be shown as a circle, an oval, or (typically) a rectangular box.
  • Data are generally shown as arrows coming to, or going from the edge of a process box.
    (Note that there is no 'Decision' symbol. A decision is a Process).



General Data Flow Rules:

  1. Entities are either 'sources of' or 'sinks' for data input and outputs - i.e. they are the originators or terminators for data flows.
  2. Data flows from Entities must flow into Processes.
  3. Data flows to Entities must come from Processes.
  4. Processes and Data Stores must have both inputs and outputs (What goes in must come out!).
  5. Inputs to Data Stores only come from Processes.
  6. Outputs from Data Stores only go to Processes.
Symbols:

Processes transform or manipulate data. Each box has a unique number as identifier (top left) and a unique name (an imperative - e.g. 'do this' - statement in the main box area) The top line is used for the location of, or the people responsible for, the process. Processes are 'black boxes' - we don't know what is in them until they are decomposed Processes transform or manipulate input data to produce output data. Except in rare cases, you can't have one without the other.

Nota: Nosotros lo representamos con un circulo y el numero identidicador lo ponemos en la parte superior central del mismo. (Aunque me parece mas prolijo de esta forma, pero va en gustos).




Data Flows depict data/information flowing to or from a process. The arrows must either start and/or end at a process box. It is impossible for data to flow from data store to data store except via a process, and external entities are not allowed to access data stores directly. Arrows must be named. Double ended arrows may be used with care .

Nota: Habla de usar las flechas bidireccionales con cuidado, en clases se explico que se utilizan cuando el intercambio de datos transcurre al mismo tiempo.




External Entities , also known as 'External sources/recipients, are things (eg: people, machines, organisations etc.) which contribute data or information to the system or which receive data/information from it.

The name given to an external entity represents a Type not a specific instance of the type.

When modelling complex systems, each external entity in a DFD will be given a unique identifier. It is common practice to have duplicates of external entities in order to avoid crossing lines, or just to make a diagram more readable.

Nota: Bueno, lo vamos a representar con un rectangulo por lo general, el identificador unico no lo usamos y si vamos a usar el duplicado de lo mismos para evitar cruzar lineas porque el diagrama tiene que ser lo mas entendible posible.





Data Stores are some location where data is held temporarily or permanently.
In physical DFDs there can be 4 types.
D = computerised Data
M = Manual, e.g. filing cabinet.
T = Transient data file, e.g. temporary program file
T(M) = Transient Manual, e.g. in-tray, mail box.

As with external entities, it is common practice to have duplicates of data stores to make a diagram less cluttered.



Nota: Las bases de datos como las damos con gustavo no las vamos a especificar tanto simplemente escribimos el nombre de esta entre dos lineas perpendiculares.







DFD Levels
The Context and Top Level diagram by themselve are not enough; they only provide a high level description. On the other hand, the initial diagrams do start to break down, decompose, what might be quite a complex system into manageable parts.
Each Process box in the Top Level diagram will itself be made up of a number of processes, and will need to be decomposed as a second level diagram.
Any box in the second level decomposition may be decomposed to a third and then a fourth level. Very complex systems may possibly require decomposition of some boxes to further levels.
Decomposition stops when a process box can be described with an Elementary Process Description using ordinary English, later on the process will be described more formally as a Function Description using, for example, pseudocode.

Nota: Nosotros vamos a trabajar dos capas (y en caso de que buscaramos descomponerlo todo lo posible seria hasta que se pueda describir usando español simple jajaja).






Webgrafia:

http://www.cems.uwe.ac.uk/~tdrewry/dfds.htm

Notas: Damian Merino

viernes, 5 de septiembre de 2008

Algo sobre cursogramas

Cursogramas
El cursograma o flujo grama es la representación gráfica del sentido, curso, flujo o recorrido de una masa de información o de un sistema o poroceso adminitrativo u operativo, dentro del contexto de la organización, mediante la utilización de símbolos convencionales que representan operaciones, registraciones, controles, etc., que ocurren o suceden en forma oral u escrita en el quehacer diario del ente.
Podríamos decir que el cursograma tiene tres "elementos básicos" que son:
se trata de un diagrama o representación gráfica;
representa el fluir de información ya sea de tipo verbal o escrito;
se refiere siempre a un proceso de tipo administrativo u operación específica.
Este método tiene su origen dentro del área de la teoría de los gráficos, sus antecedentes se remontan a los gráficos utilizados por los ingenieros en los diagramas industriales, que representaban las actividades de producción como, por ejemplo: los diagramas de proceso de la operación industrial, los de recorrido y los denominados "mano izquierda - mano derecha."
Los cursogramas tienen dos grandes partes componentes:
Simbología: la simbología utilizada representa la operación o proceso y el fluir o recorrido de la información.
Diagramación: la forma de realizar, dibujar o graficar depende de los siguientes factores a tener en cuenta:
Lenguaje a usar: el conjunto de señales que dan a entender una cosa;
Método a desarrollar: mantener un modo razonado de obrar o proceder.
Uno de los problemas que tiene este método es que no existe una simbología de carácter universal, es decir que falta uniformidad en cuanto a su interpretación simbólica.
Contenido de la documentación.
Los papeles de trabajo contendrán:
Por sistemas: el flujo general de las operaciones y transacciones.
Las áreas o los sectores que intervienen en cada procedimiento.
Los controles vigentes y la forma en que se practican.
Determinación en cada sistema de:
Formulario
Autorizaciones de validez
Registros
Archivos
Verificación de las descripciones de los sistemas.
Finalizada la etapa anterior, se deberá proceder a:
Confirmar lo conocido, mediante la realización de una prueba de auditoría, que consistirá en verificar el cumplimiento de todo lo relevado.
La prueba consistirá en realizar el seguimiento de una operación o transacción a través de cada paso de sistema para poder determinar si la información se procesa en la forma descripta.
Si existen discrepancias, éstas pueden tener origen en:
Error o defecto en la descripción realizada del sistema, en este caso se debe practicar la corrección de la misma.
Error o deficiencia de sistema operante. Esta alternativa se deberá tener muy en cuenta en el momento de la evaluación final de las actividades de control.
En los papeles de trabajo se detallaran todas las pruebas efectuadas y las conclusiones a las que se llegaron.
Evaluación de las actividades de control de los sistemas.
Identificación de los controles existentes: Finalizado el relevamiento y la descripción de los sistemas, hay que detectar los controles existentes en los sistemas y su efectividad.
Errores potenciales: Pueden ocurrir estos tipos o clases
Transacciones registradas:
Que no son válidas;
En períodos incorrectos;
En forma incorrecta o incompleta;
Transacciones incorrectamente:
Salvadas o corregidas;
Imputadas;
Registradas en el período.
Transacciones no:
Registradas;
Autorizadas o aprobadas.
Verificación de la capacidad de las actividades de control de los sistemas operantes para: prevenir, detectar y corregir los errores potenciales.
Para determinar el grado de confiabilidad de los controles existentes, sobre la base de la capacidad de las actividades de control, se deberá establecer la ocurrencia de posibles o potenciales errores en los sistemas y su incidencia en los estados contables.
La presente clasificación permitirá evaluar la alternativa de confiar o no en las actividades de control de los sistemas existentes.
Pruebas de las actividades de control de los sistemas: Si se está en condiciones de confiar en las actividades de control de los sistemas, se procede a evaluar las actividades reales de control.
La verificación de la realidad se hará:
Seleccionando una muestra de las transacciones u operaciones que será representativa del todo.
En cada caso se verificará el funcionamiento y comportamiento de los controles existentes.
Los papeles de trabajo contendrán:
Pruebas efectuadas;
Resultados obtenidos.
En caso de que no se confíe en las actividades de control de los sistemas, no es necesario efectuar prueba alguna.
Resultado de la evaluación de las actividades de control de los sistemas.
Las actividades de control de los sistemas son eficientes. Si se decide confiar en las actividades de control de los sistemas y los resultados de las pruebas han sido satisfactorias, el auditor basará su labor en dichas actividades y las tendrá en cuenta al determinar la naturaleza, naturalieza, el alcance y la oportunidad de los procedimientos de auditoria a aplicar.
Las actividades de control de los sistemas son deficientes. Si se ha determinado que las actividades de control de los sistemas no son confiables o los resultados de las pruebas sobre las mismas no son satisfactorias, no se confiará en dichas actividades. Por lo tanto, al programarse la naturaleza, el alcance y la oportunidad de los procedimientos, se contemplará la realización de una prueba mayor, y de análisis superior.
Características de los flujogramas
· De uso, permite facilitar su empleo.
· De destino, permite la correcta identificación de actividades.
· De comprensión e interpretación, permite simplificar su comprensión.
· De interacción, permite el acercamiento y coordinación.
· De simbología, disminuye la complejidad y accesibilidad.
· De diagramación, se elabora con rapidez y no requiere de recursos sofisticados.

Cómo se construye
· Debe de indicar claramente dónde inicia y dónde termina el diagrama.
· Cualquier camino del diagrama debe de llevarte siempre a la terminal de fin.
· Organizar los símbolos de tal forma que siga visualmente el flujo de arriba hacia abajo y de izquierda a derecha.
· No usar lenguaje de programación dentro de los símbolos.
· Centrar el diagrama en la página.
· Las líneas deben ser verticales u horizontales, nunca diagonales.