Metodologias agiles

Beneficios que aporta RUP

• Permite desarrollar aplicaciones sacando el máximo provecho de las nuevas tecnologías, mejorando la calidad, le rendimiento, la reutilización, la seguridad y el mantenimiento del software mediante una gestión sistemática de los riesgos. [ANO05, 1].
• Permite la producción de software que cumpla con las necesidades de los usuarios, a través de la especificación de los requisitos, con una agenda y costo predecible. [ANO05,1].
• Enriquece la productividad en equipo y proporciona prácticas óptimas de software a todos sus miembros. [ANO05, 2].
• Permite llevar a cabo el proceso de desarrollo práctico, brindando amplias guías, plantillas y ejemplos para todas las actividades críticas. [ANO05, 2].
• Proporciona guías explicitas para áreas tales como modelado de negocios, arquitectura Web, pruebas y calidad. También se proporciona guías para desarrollar en plataformas IBM WebSphere y Microsoft Web Solution para acelerar el desarrollo de los proyectos. [ANO05, 2].
• Se integra estrechamente con herramientas Rational, permitiendo a los equipos de desarrollo aprovechar todas las ventajas de las características de los productos Rational, el Lenguaje de Modelado Unificado (UML) y otras prácticas óptimas de la industria. [ANO05, 2].
• Unifica todo el equipo de desarrollo de software y mejora la comunicación al brindar a cada miembro del mismo una base de conocimientos, un lenguaje de modelado y un punto de vista de cómo desarrollar software. [ANO05, 2].
• Optimiza la productividad de cada miembro del equipo al poner al alcance la experiencia derivada de miles de proyectos y muchos líderes de la industria.
• No solo garantiza que los proyectos abordados serán ejecutados íntegramente sino que además evita desviaciones importantes respecto a los plazos. [ANO05, 3].
• Permite una definición acertada del sistema en un inicio para hacer innecesarias las reconstrucciones parciales posteriores. [ANO05, 3].

Metodologías ágiles.

XP

La Programación Extrema surge ideada por Kent Beck, como proceso de creación de software diferente al convencional. En palabras de Beck: "XP es una metodología ligera, eficiente, con bajo riesgo, flexible, predecible y divertida para desarrollar software".

Objetivos de XP:

Los objetivos de XP son muy simples: la satisfacción del cliente. Esta metodología trata de dar al cliente el software que él necesita y cuando lo necesita. Por tanto, debemos responder muy rápido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de la programación.

El segundo objetivo es potenciar al máximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y están involucrados en el desarrollo del software.

Bases de XP

La programación extrema se basa en la simplicidad, la comunicación y el reciclado continuo de código, para algunos no es más que aplicar una pura lógica. Lo que buscan en definitiva es la reducción de costes.

Valores XP

Una de las cosas que a los programadores nos tiene que quedar muy claro es que en el ciclo de vida del desarrollo de un proyecto software los cambios van a aparecer, cambiarán los requisitos, las reglas de negocio, el personal, la tecnología, todo va a cambiar. Por tanto el problema no es el cambio en si, ya que este va a suceder sino la incapacidad de enfrentarnos a estos cambios.

Como en otra cualquier actividad humana necesitamos valores para desarrollar nuestro trabajo y conseguir los planteamientos iniciales.

Estos cuatro valores son:

• Comunicación
• Sencillez
• Retroalimentación
• Valentía

Variables XP

XP define cuatro variables para proyectos de software:

• Coste
• Tiempo
• Calidad
• Ámbito.

Actividades básicas XP

Ahora que tenemos nuestros cuatro valores estamos preparados para construir una disciplina de desarrollo de software. ¿Qué tareas debemos de llevar a cabo para desarrollar un buen software?

Codificar

Es la única actividad de la que no podremos prescindir. Sin código fuente no hay programa, aunque hay gente que cuenta que existe software en producción del que se perdió el código fuente. Por tanto necesitamos codificar y plasmar nuestras ideas a través del código. En una programación en XP en pareja el código expresa tu interpretación del problema, así podemos utilizar el código para comunicar, para hacer mías tus ideas, y por tanto para aprender y mejorar.

Hacer pruebas

Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas me dan la oportunidad de saber si lo que implementé es lo que en realidad yo pensaba que había implementado. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema entonces has acabado por completo.

No debemos de escribir tan solo una prueba ver que funciona y salir corriendo, debemos de pensar en todas las posibles pruebas para nuestro código, con el tiempo llegarás a conclusiones sobre las pruebas y podrás pensar que si dos de tus pruebas ya funcionan la tercera prueba no será necesaria escribirla, sin caer en demasiada confianza.

Programar y probar es más rápido que sólo programar. Puedes ganar media hora de productividad sin hacer pruebas, pero perderás mucho tiempo en la depuración. Tendrás menos errores, tendrás que volver menos veces sobre el código, te costará menos localizar los errores, perderás menos tiempo escuchado como tus clientes te dicen que no funciona.

Las pruebas deben de ser sensatas y valientes. No podemos hacer pruebecillas que no testen a fondo el sistema, esos agujeros que vamos dejando nos esperan para cuando pasemos de nuevo por allí y volveremos a caer dentro.

Escuchar

Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software ¿ para que nos querrían ?.

Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la información. Tenemos que escuchar a nuestros clientes cuales son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la realimentación entre ambos nos ayudan a todos a entender los problemas.

Diseñar

El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, divídela en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes.

Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente.

Prácticas Básicas de XP

El juego de la planificación.

Hay una comunicación frecuente el cliente y los programadores. El equipo técnico realiza una estimación del esfuerzo requerido para la implementación de las historias de usuario y los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración.

Pequeñas versiones.

Cada versión debe de ser tan pequeña como fuera posible, conteniendo los requisitos de negocios más importantes, las versiones tiene que tener sentido como un todo, me explico no puedes implementar media característica y lanzar la versión.

Es mucho mejor planificar para 1 mes o 2 que para seis meses y un año, las compañías que entregan software muy voluminoso no son capaces de hacerlo con mucha frecuencia.

Metáfora.

Una metáfora es una historia que todo el mundo puede contar a cerca de cómo funciona el sistema. Algunas veces podremos encontrar metáforas sencillas "Programa de gestión de compras, ventas, con gestión de cartera y almacén". Las metáforas ayudan a cualquier persona a entender el objeto del programa.

Diseño sencillo.

El diseño adecuado par el software es aquel que:

1. Funciona con todas las pruebas.

2. No tiene lógica duplicada.

3. Manifiesta cada intención importante para los programadores

4. Tiene el menor número de clases y métodos.

Haz el diseño lo más simple posible borra todo lo que puedas sin violar las reglas 1,2 y 3. Contrariamente a lo que se pensaba el "Implementa para hoy, diseña para mañana", no es del todo correcto si piensas que el futuro es incierto.

Hacer pruebas.

No debe existir ninguna característica en el programa que no haya sido probada, los programadores escriben pruebas para chequear el correcto funcionamiento del programa, los clientes realizan pruebas funcionales. El resultado un programa mas seguro que conforme pasa el tiempo es capaz de aceptar nuevos cambios.

Recodificación.

Cuando implementamos nuevas características en nuestros programas nos planteamos la manera de hacerlo lo mas simple posible, después de implementar esta característica, nos preguntamos como hacer el programa mas simple sin perder funcionalidad, este proceso se le denomina recodificar o refactorizar (refactoring). Esto a veces nos puede llevar a hacer mas trabajo del necesario, pero a la vez estaremos preparando nuestro sistema para que en un futuro acepte nuevos cambios y pueda albergar nuevas características. No debemos de recodificar ante especulaciones si no solo cuándo el sistema te lo pida.

Programación por parejas.

Todo el código de producción lo escriben dos personas frente al ordenador, con un sólo ratón y un sólo teclado. Cada miembro de la pareja juega su papel: uno codifica en el ordenador y piensa la mejor manera de hacerlo, el otro piensa más estratégicamente, ¿Va a funcionar?, ¿Puede haber pruebas donde no funcione?, ¿Hay forma de simplificar el sistema global para que el problema desaparezca?

El emparejamiento es dinámico, puedo estar emparejado por la mañana con una persona y por la tarde con otra, si tienes un trabajo sobre un área que no conoces muy bien puedes emparejarte con otra persona que si conozca ese área. Cualquier miembro del equipo se puede emparejar con cualquiera.

Propiedad colectiva.

Cualquiera que crea que puede aportar valor al código en cualquier parcela puede hacerlo, ningún miembro del equipo es propietario del código. Si alguien quiere hacer cambios en el código puede hacerlo. Si hacemos el código propietario, y necesitamos de su autor para que lo cambie entonces estaremos alejándonos cada vez mas de la comprensión del problema, si necesitamos un cambio sobre una parte del código lo hacemos y punto. XP propone un propiedad colectiva sobre el código nadie conoce cada parte igual de bien pero todos conoce algo sobre cada parte, esto nos preparará para la sustitución no traumática de cada miembro del equipo.

Integración continúa.

El código se debe integrar como mínimo una vez al día, y realizar las pruebas sobre la totalidad del sistema. Una pareja de programadores se encargara de integrar todo el código en una maquina y realizar todas las pruebas hasta que estas funcionen al 100%.

40 Horas semanales.

Si queremos estar frescos y motivados cada mañana y cansado y satisfecho cada noche. El viernes quiero estar cansado y satisfecho para sentir que tengo dos días para pensar en algo distinto y volver el lunes lleno de pasión e ideas. Esto requiere que trabajemos 40 horas a la semana, mucha gente no puede estar más de 35 horas concentrados a la semana, otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas durante varias semanas y aun seguir fresco, creativo y confiado. Las horas extras son síntoma de serios problemas en el proyecto, la regla de XP dice nunca 2 semanas seguidas realizando horas extras.

Cliente In-situ.

Un cliente real debe sentarse con el equipo de programadores, estar disponible para responder a sus preguntas, resolver discusiones y fijar las prioridades. Lo difícil es que el cliente nos ceda una persona que conozca el negocio para que se integre en el equipo normalmente estos elementos son muy valiosos, pero debemos de hacerles ver que será mejor para su negocio tener un software pronto en funcionamiento, y esto no implica que el cliente no pueda realizar cualquier otro trabajo.

Estándares de codificación.

Si los programadores van a estar tocando partes distintas del sistema, intercambiando compañeros, haciendo refactoring, debemos de establecer un estándar de codificación aceptado e implantado por todo el equipo.

Características esenciales de XP

• Roles.

• Programador: Produce el código del sistema.
• Cliente: Escribe las HU y las pruebas funcionales para validar su implementación, así como asigna la prioridad de la HU y decide cuál se implementara en cada iteración.
• Encargado de pruebas: Ayuda al cliente a escribir las pruebas funcionales, ejecuta las pruebas y difunde resultados además es responsable de las herramientas de soporte para prueba.
• Rastreador (Tracker): también conocido como "Metric Man", observa sin molestar y mantiene los datos históricos.
• Consultor: Es un miembro externo del equipo con conocimiento especifico de algún tema necesario para el proyecto. Guía al equipo para resolver un problema específico.
• Gestor (Big Boss): Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.

• Artefactos esenciales.

• Historias de Usuario.
• Tareas de Ingeniería.
• Pruebas de Aceptación.

• Procesos.

Ciclo de desarrollo.

Ciclo de vida(Fases)

1. Exploración
2. Planificación.
3. Iteraciones.
4. Producción.
5. Mantenimiento.
6. Muerte Proyecto.

• Prácticas.

3P [ECH08].

Paradigma 3P es una metodología de desarrollo de software nacida al calor de la experiencia acumulada del grupo de investigación y desarrollo Atis debido a la insuficiente capacidad de respuesta a los clientes utilizando las metodologías tradicionales.

Principios que sustentan el modelo

1. Los individuos y sus interacciones son más importantes que los procesos y las herramientas: El PERSONAL.
2. La comunicación con el cliente evita construir una elegante solución para un problema equivocado: El PROBLEMA.
3. El software que funciona es más importante que la documentación exhaustiva. El PROCESO.

Valores 3P

1. Comunicación: Sin comunicación todo proyecto estaría destinado a fracasar , comunicar no es escribir o hablar muchas palabras sino utilizar solo las palabras necesarias para trasmitir una idea.
2. Sencillez: Nadie es mejor o peor que los demás miembros del grupo de desarrollo , todos tenemos fortalezas y debilidades, conocerlas hará que nuestras relaciones con los miembros del grupo sean mejores en el orden profesional y personal.
3. Retroalimentación: Saber cuándo se debe rehacer algo que no funciona, equivocarse es de humanos, encarar nuevamente la tarea con emprendimiento y optimismo.
4. Emprendimiento: estar dispuesto siempre a acometer las tareas más complejas, encararla con esmero y con alegría hará que crezca nuestro prestigio entre los demás miembros, la convicción y el deseo del triunfo debe prevalecer.
5. Optimismo: Ser realista pero tener siempre el pensamiento orientado hacia el éxito.

Actividades básicas

1. Codificar.
2. Probar.
3. Comunicar
4. Idear
5. Escuchar.
6. Diseñar.

Roles del proyecto

1. Jefe del Proyecto
2. Cliente
3. Consultor
4. Analista-Programador
5. Programador
6. Diseñador de Interfaces

Principios que sustentan la metodología

1. EL Personal: Gestión de Proyecto
2. El Problema: Gestión del Cliente
3. El Proceso: Ciclo de Vida de Desarrollo

Ciclo de vida de desarrollo

1. Definición del problema.
2. Identificación de los procesos unitarios.
3. Diseño del prototipo.
4. Desarrollo del prototipo.
5. Prueba del prototipo.
6. Si ir a Paso 3.
7. Si ir a Paso 2.
8. Si ir a Paso 2.
9. Implantación.
10. Mantenimiento.

Resumen puntos clave

RUP

• Pesado
• Dividido en cuatro fases, que se dividen en iteraciones
• El discurrir del proyecto se define en Workflows
• Los artefactos son el objetivo de cada actividad
• Se basa en roles
• UML
• Muy organizativo
• Mucha documentación

3P

• Ágil
• Cercano al desarrollo, pero sin olvidar el diseño.
• Se basa en 3 principios: Personal, Problema, Proceso.
• Gran interacción con el cliente.
• Pruebas de funcionalidad y calidad.
• Logra alcanzar un control y organización del proceso.
• Logra un equilibrio en cuanto a la generación de documentación

XP

• Ligero
• Cercano al desarrollo
• Se basa en UserStories
• Fuerte comunicación con el cliente
• El código fuente pertenece a todos
• Programación por parejas
• Tests como base de la funcionalidad
• Solo el mínimo de organización
• Pobre en cuanto a documentación

3. Conclusiones

¿Qué debemos esperar entonces de un proceso de desarrollo?

¿Qué criterios debe cumplir para que aporte algo a la empresa?

Básicamente el proceso de desarrollo tiene que ayudarnos a escribir software, tiene que poner las reglas necesarias para alcanzar el éxito en nuestro proyecto pero dejando la libertad suficiente para no sentirnos agobiados.

Esto no nos lo va a ofrecer ningún proceso estándar, y como dice el refrán (aunque no se cumple exactamente en el mundo de la informática) todos los caminos conducen a Roma.

De forma que es tarea de cada empresa, casi para cada proyecto, decidir cual es el mejor modo de llegar a nuestra meta.

Rational Unified Process (RUP)

What is RUP?

RUP is a risk-driven, use-case-based, and architecture-centric, iterative software development process. RUP embodies industry-standard management and technical methods and techniques to provide a software engineering process particularly suited to creating and maintaining component-based software system solutions. RUP communicates roles, activities, and artifacts organized by process workflows that guide project teams through software engineering disciplines under the purview of operational business phases and decision making milestones.

RUP's foundation consists of three key elements: the role, the activity, and the artifact, as shown in Figure 1. The role performs activities and produces artifacts. Each role is primarily responsible for a set of activities and artifacts. But all roles will contribute to other activities and artifacts. Roles, activities, and artifacts are used repeatedly during the execution of workflows. The workflows form a sequence of tasks unique to each of the nine software disciplines in the RUP iterative development software lifecycle framework (see Figure 2).

Figure 1: Key elements of IBM Rational Unified Process

Figure 2: RUP framework

The RUP framework is two dimensional, with axes indicating time and content. The time dimension is organized by phases, iterations, and milestones. The content dimension consists of software disciplines containing the workflows, roles, activities, and artifacts as they apply to that discipline.

You implement the RUP framework via a complementary toolset, the capabilities of which generally map to the types of activities and artifacts required (Figure 3).

Figure 3: The RUP framework is implemented via a complementary toolset

As shown in Figure 3, RUP consists of five distinct parts:

1. The RUP process framework. This is the knowledge base of industry-proven best practices that forms the heart of RUP.
2. The process delivery tools. These are the tools that deliver the valuable process content to the practitioner when needed, in the form and quantity they need.
3. The Rational Process Workbench. This consists of RUP Organizer and RUP Modeler. RUP Organizer allows you to create simple plug-ins that complement, without altering, RUP's underlying structure. RUP Modeler allows you to create structural plug-ins for RUP that change RUP's underlying meta-model.
4. The Configuration tool. Otherwise known as RUP Builder, helps RUP users configure a base RUP configuration with the plugins created in RUP Organizer and RUP Modeler.
5. IBM developerWorks. The Rational developer domain on IBM developerWorks (http://www-136.ibm.com/developerworks/rational) hosts an active community of RUP users and RUP partners that can help customers optimize their use of RUP.

Microsoft Project

Diagrama de transicion de estados (DTE)

Diagramas de transición de estados.

---

El diagrama de transición de estado (también conocido como DTE) enfatiza el comportamiento dependiente del tiempo del sistema. Este tipo de modelo sólo importaba para una categoría de sistemas conocido como sistemas de tiempo-real; como ejemplo de estos sistemas se tienen el control de procesos, sistemas de conmutación telefónica, sistemas de captura de datos de alta velocidad y sistemas de control y mando militares.

En la figura 4.3.1 se muestra un DTE típico. Este diagrama muestra el comportamiento de una máquina contestadora de teléfono normal. Los principales componentes del diagrama son estados, y flechas que representan los cambios de estado.

Figura 4.3.1: Diagrama de transcisión de estados.

Cada rectángulo representa un estado en el que se puede encontrar el sistema. Pudiendo ser este:

• Esperar a que el usuario dé su contraseña.
• Calentar una mezcla de sustancias químicas.
• Esperar la siguiente orden.
• Acelerar el motor.
• Mezclar los ingredientes.
• Esperar datos del instrumento.
• Llenar el tanque.
• Aguardar en reposo.

Cambios de estado.

¿Cómo cambia un sistema de un estado a otro?. Sí se tienen reglas ordenadas que gobiernan su comportamiento, entonces generalmente sólo algunos tipos de cambio de estado serán significativo y válidos.

Se muestran los cambios de estado válidos en el DTE conectando pares relevantes de estado con una flecha. Así, la figura 4.3.2 muestra que el sistema puede ir del estado 1 al estado 2. También muestra que cuando el sistema se encuentra en el estado 2 puede ir al estado 3 o regresar al 1.

Figura 4.3.2:Cambios de estados.

A pesar de que la figura 4.3.2 proporciona información interesante acerca del comportamiento dependiente del tiempo de un sistema, no dice cuales son los estados inicial y final del sistema. La mayoría de los sistemas tienen un estado inicial reconocible y estado final reconocible; esto se muestra en la figura 4.3.3.

Figura 4.3.3:Estados inicial y final.

Lo que identifica al estado 1 de la figura 4.3.3 como inicial es la flecha "desnuda" que no está conectada a ningún otro estado, y lo que identifica al estado 5 como final es la ausencia de una flecha que salga de él.

El sentido común dice que un sistema sólo puede tener un estado inicial; sin embargo, puede tener múltiples estados finales. Los estados finales son mutuamente excluyentes, lo cual significa que sólo uno de ellos puede ocurrir durante alguna ejecución del sistema.

Condiciones y acciones.

Para completar nuestro DTE necesitamos añadir dos cosa más: las condiciones que causan un cambio de estado y las acciones que el sistema toma cuando cambia de estado. Como ilustra la figura 4.3.4, las condiciones y acciones se muestran junto a la flecha que conecta dos estados relacionados.

Figura 4.3.4:Muestra de condiciones y acciones.

Una condición es un acontecimiento en el ambiente externo que el sistema es capaz de detectar; típicamente es una señal, una interrupción o la llegada de un paquete de datos. Esto usualmente hace que el sistema cambie de un estado de espera X a un estado de espera Y; o de llevar a cabo la actividad X a llevar acabo la actividad Y. Como parte del cambio de estado, normalmente hará una o más acciones: producirá una salida, desplegará una señal en la terminal del usuario, llevará a cabo un cálculo, etc.

Construcción del diagrama de transición de estados.

Así como en los DFD se utilizó la partición también es recomendable usarla en los DTE en donde los sistemas son muy complejos.

Para la construcción de DTE se puede seguir cualquiera de dos enfoques:

1. Se puede comenzar por identificar todos los posibles estados del sistema y representar cada uno como una caja separada en una hoja de papel. Luego, se pueden explorar todas las conexiones con significado (es decir, los cambios de estado) entre las cajas.

2. Como alternativa, se puede comenzar por el estado inicial, y luego metódicamente ir siguiendo un camino hasta el o los estados restantes; luego de los estados secundarios, proseguir a los terciarios; etc.

Cuando se termina de construir el DTE preliminar, deben seguirse las siguientes reglas para verificar la consistencia:

• ¿Se han definido todos los estados?.
• ¿Se pueden alcanzar todos los estados?. ¿Se han definido estados que no tengan caminos que lleven a ellos?
• ¿Se puede salir de todos los estados?
• ¿El sistema responde adecuadamente a todas las condiciones posibles?

El DTE representa una especificación de proceso para una burbuja de control en DFD. Como herramienta de modelado de alto nivel, el DTE puede servir incluso como especificación de proceso para todo el sistema. Si se representa todo el sistema como un diagrama de una burbuja, puede usarse el DTE para mostrar la secuencia de actividades en el sistema.

Visio 2007

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

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.