1 Resumen Yourdon ¿Qué es un sistema?
Definición: Conjunto de componentes interrelacionados y sus atributos, los cuales comparten un objetivo en común. o
Sistema abstracto: es aquel que es fruto de la mente humana. Ej: Sistema Social.
o
Sistema físico: están compuestos por componentes físicos. Ej: Sistema Educativo.
Elementos:
o
Limite: separa y demarca el sistema del ambiente. En esencia el límite lími te no presenta mayor problema pero dependiendo del mismo y de quien hace la observación el l ímite puede volverse algo bastante abstracto. ¿Qué es Información?
Concepto: Son datos procesados en forma significativa para el receptor, con valor real y perceptible para la toma de decisiones presentes o futuras. Es decir que los datos pasan por un proceso el cual les agrega utilidad, finalidad y significado, convirtiéndolos en información. Esta información sirve para quitar incertidumbre. Hecho: Representación de la realidad de un momento dado. Es verificable, cuantificable y verdadero. Dato: Representación de un hecho. Son las características de los hechos. Pueden ser procesados y transmisibles.
Características: o o o o o o o o
o o o
Precisión: que sea lo mas exacta posible (menor margen de error posible) Frecuencia: que tenga periodicidad. Forma: La manera en que se presenta la información: Narrativa o cuantificable. Relevancia: la información es importante si me sirve para tomar una decisión en ese momento. Oportunidad: debe estar en el momento en que se precisa. Utilidad: Debe ser utilizada en tiempo y forma. Ahora es útil, mañana ¿Quién sabe? Comparavilidad: Debe poder ser cotejada con otra información. En tiempo/espacio/alcance. Flexibilidad: me debe acompañar y adecuarse a los tiempos de los negocios. Es decir, fácilmente modificable. Claridad: De fácil entendimiento. Que no presente ambiguedades Confiabilidad: que sea fiable en la fuente, en la presentación, en el proceso. Beneficiosa: es decir que el costo sea el minino y el valor de la misma sea el mas alto posible.
2
E
S Procesar
Datos
Información
Hechos
Decisión
La información debe ser: Relevante/Util, oportuna, confiable, que no presente ambiguedades (clara), precisa, relación costo/beneficio.
Costo $
Oportuno
T
El costo de la información es menor si se la consigue en el momento oportuno, a su vez si se la obtiene antes del momento oportuno aumenta el costo de la información por que hay que verificar al momento de utilizarla que este actualizada. Si se la consigue luego del momento oportuno no es útil y se gastaron recursos en conseguir información que ya no es necesaria.
Valor $
Oportuno
T
Valor de la información: cual es el valor que le da la persona que recibe la información (importancia). Cuanto pierdo si no tengo la información. Si la consigo antes, el valor de la información es menor ya que en ese momento no me es útil. Si la consigo después del momento oportuno, ya no me sirve por lo tanto el valor es menor. En conclusión, la información sirve (tiene valor) si es obtenida en el momento oportuno.
3
$ Beneficio
T El beneficio de la información es la diferencia entre lo que me cuesta y el valor que le doy a la misma. Elementos o personas que intervienen en un sistema
Usuario: Es el participante mas importante, puesto que el sistema se crea para él. Se lo tendrá que entrevistar con gran detalle dado que este nos dará los detalles que harán de nuestro proyecto un éxito o un fracaso. Normalmente los Usuarios no se refieren a si mismos como usuarios sino como clientes o dueño. El cliente como tal, siempre tiene la razón y además, es el que a fin de cuentas paga. Es fácil identificar al usuario, puesto que es el que formalmente solicita un sistema. Aunque no siempre es tan fácil identificarlo y tener contacto con el, es de suma importancia tener un contacto directo con el. Y de no ser posible, la documentación generada por el analista cobra mayor importancia. Normalmente cuando uno piensa en los usuarios presupone que son “todos iguales” cuando en verdad la realidad es muy diferente. Se pueden hacer las siguientes clasificaciones.
Por Categoría de trabajo: Operacionales: Son operadores que tendrán contacto diario con el sistema. Tiende a ponerse en contra de los cambios. Hay que tener en cuenta 3 cosas cuando se trate con estos usuarios. Se preocupan mucho por las funciones del sistema, se preocupan aun más por la internas humana. Este detalle y otros que puedan surgir de la entrevista con el usuario son vitales para el proyecto. Solo conocen su trabajo específico y no entienden del panorama global. El analista debe usar un lenguaje que le sea familiar al usuario para luego traducirlo a un modelo esencial.
Supervisores: Son empleados supervisores que manejan grupos de usuarios operacionales. A tener en cuenta: Muchos son usuarios operacionales promovidos, por tanto estarán de acuerdo con sus subordinados. El supervisor tiende a ver al nuevo proyecto como una forma de reducir el número de usuarios operacionales. Esto no es ni bueno ni malo pero puede dar a discusiones en donde el analista quede involucrado. Tiende a tratar de ser un nexo entre el operacional y el analista. Esto es peligroso, porque probablemente no refleje exactamente lo que el o peracional busca. Tratar de evitarlo es esencial. Su visión es tan local como la del operacional. Será con el que mas contacto se tenga durante el desarrollo del proyecto.
4
Ejecutivo: Son los que por lo general no se involucran directamente con el proyecto pudiendo estar dos o tres niveles arriba del supervisor. A tener en cuenta: Es probable que solo sirva como autoridad para financiar. Por lo general no fueron empleados operacionales, por tanto no tiene los conocimientos necesarios para poder definir los requerimientos del sistema para aquellos que trabajan con el sistema todos los días. No están interesados por asuntos operacionales sino en los detalles estratégicos y las ganancias/perdidas a largo plazo. Se interesan por el panorama global y no por los detalles Están acostumbrados a trabajar con modelos abstractos.
Por nivel de experiencia: Amateurs: Aquel que jamás ha visto una computadora. Es todo un reto para el analista dado que presenta un problema a la hora de la comunicaciones y hay que tratar de hablar en los términos que le sean más familiar al usuario. Novato Presuntuoso: Es un usuario que alega saber exactamente lo que quiere haga el sistema dado sus conocimientos en informática. Tiende a hacer sugerencias sobre la tecnología a usar para el desarrollo. Verdaderos expertos: Usuarios que realmente entiende el análisis de sistemas y también las tecnologías de computadora.
Administración: La reilación que se tiene con estos administradores tiene que ver con la asignación de recursos: personas, tiempo y dinero. Es nuestra tarea como analistas documentar todos estos datos. Existen diversos tipos: Administrador usuario: Están a cargo de varias personas en el área operacional donde se va a implementar el nuevo sistema. Administrador de informática: son las personas encargadas del proyecto en si de sistemas y los administradores de nivel superior. Administrador general: Son los administradores de nivel superior que no están directamente involucrados con la organización de informática ni son de la organización usuaria. Puntos a tener en cuenta: Cuanto más alto el nivel que ocupen es más probable que desconozcan sobre tecnologías de computadoras. Las metas entre administradores y usuarios pudieran entrar en conflicto. Pudiera ser que los administradores no estén dando los recursos necesarios para la implementación efectiva del nuevo sistema. Pudiera ser también que entre los administradores tengamos creyentes y escépticos en la implementación es un nuevo sistema. Pudiera también que los administradores se vieran forzados a reducirle los recursos al proyecto.
5
Auditores: Según sea el tamaño del proyecto pudiera haber auditores, personal de control de calidad, etc. Su objetivo es asegurar que el sistema se desarrolle desacuerdo a diversos estándares o normas externos al proyecto. A tener en cuenta: A menudo no se involucran hasta el final en el proyecto, y a esas alturas es dócil hacer cambios. Es importante que el sistema sea compatible con viejas notaciones o formatos antiguos. Se interesan más por la forma y no por el contenido.
Analista de sistemas: Personaje clave puesto que cumple var ios papeles: Arqueólogo y escribano: Descubre detalles y documenta la política de un negocio. Innovador: Con sus conocimientos de informática debe proponer soluciones novedosas y más útiles a problemas del usuario. Mediador: entre los otros participes de este juego que comúnmente está en desacuerdo. Y busca un consenso. Jefe de proyecto: suele asignársele la administración del proyecto integra Esto significa que se requiere facilidad en el manejo de personas para poder entrevistar a los usuarios y mediar entre desacuerdos. Conocer los usos potenciales del hardware y el software, tener una mente lógica y organizada. Ser capas de pensar en el sistema en términos abstractos y físicos. Diseñador de sistemas: es quien recibe los datos del trabajo del analista y desarrollar un diseño arquitectónico de alto nivel que servirá de base para el trabajo de los programadores. En muchos casos el diseñador y el analista son la misma persona. Y de no ser así es importante que se mantengan en contacto a lo largo de todo el proyecto. Programadores: Se busca no tener contacto con los programadores y que ellos solo tengan contacto con el diseñador (puesto que ellos le dan el fruto de su trabajo a los programadores). Esto quiere decir que la labor del analista termina mucho antes de que el programador escriba nada. Si hay contacto entre analistas y programador puede ser por lo siguiente: En pequeños proyectos el analista, diseñador y programador son la misma persona. El analista a veces sirve de administrador del proyecto. Por lo general es el programador el que descubre ambigüedades en la propuesta de requisitos entregada por el analista. En el caso de que se estuviera remplazando un sistema muy viejo del cual no existiera documentación, la fuente principal de información seria el programador encargado del mantenimiento del sistema hasta ese momento.
Personal de operaciones: Es aquel que opera el sistema, no porque use el sistema sino porque cuida u opera a un nivel mas bajo que el administrador. Ciclo de vida de un proyecto
En las organizaciones pequeñas el proyecto nace de conversaciones entre el usuario y el administrador de proyecto y el proyecto va desde el análisis hasta el diseño e implantación sin mayor alboroto. En las organizaciones grandes, la comunicaciones suele ser por escrito el proyecto pasara por la diversas fases antes de completarse. Sirve para:
6
Definir las tareas a llevarse a cabo en un proyecto de desarrollo. Lograr congruencia entre todos los proyectos de desarrollo de una organización. Para tener puntos de control y revisión administrativos de las decisiones sobre continuar o no con un proyecto.
El objetivo es:
Para no perder de vista ni restar importancia a las diferentes etapas del desarrollo. Para simplificar el seguimiento del proyecto a los niveles mas altos de la administración. Para prever mediante los puntos de control posibles rastrazos o la falta de recursos. Y poder abordar los posibles problemas a tiempo.
El ciclo de vida de un proyecto no simplifica ni quita trabajo, simplemente es una herramienta que el administrador del proyecto para organizarse de mejor manera.
Ciclo de vida del proyecto clásico: Cada proyecto pasa por un tipo de análisis, diseño e implementación. Se caracteriza por tener una fuerte tendencia a la implantación ascendente del sistema y la instancia en la progresión lineal y secuencial de una fase a la siguiente.
Implantación Ascendente: Una de las grandes debilidades del ciclo de vida clásico. Presenta un gran número de dificultades: Nada esta hecho hasta que esta todo terminado: Es decir que si la fecha límite cae en la mitad del proyecto, no habrá nada que mostrar al usuario. Las fallas más triviales se encuentran al comienzo del periodo de prueba y las más grabes al final. La eliminación de fallas suele ser extremadamente difícil durante las últimas etapas de prueba del sistema. La necesidad de prueba con la computadora aumenta exponencialmente durante las etapas finales de prueba.
Progresión secuencial: Segunda debilidad insistencia en que las fases se sucedan secuencialmente. Tendemos a tratar de desprendernos de una etapa. El problema que esto no permite el tratamiento de problemas reales como los relacionados con el personal, la política de la compañía o la economía. Otro problema que puede surgir es el cambio de padecer por parte del cliente sobre lo que quiere que haga el sistema, sobre la marcha.
7
Cliente Encuesta
Análisis
Hacer algo mas concreto
Diseño Preliminar
El usuario nos da información (Relevamiento)
Se traduce la necesidad del usuario para empezar a trabajar.
Estudio de hardware
Codificación
Prueba de Unidad
Pasar a línea de código
Probar los programas individuales
Prueba de Subsistema
Probar los programas individuales todos juntos.
Prueba de Sistema
Probar todo junto.
S.P.
Implementación.
Ciclo de vida del proyecto semiestructurado: Dos detalles obvio respecto al clásico:
Implantación de arriba hacia abajo, es decir que se codifica y prueban los módulos de alto nivel primero y luego los de bajo nivel. El diseño clásico se reemplaza por el diseño estructurado.
Se pondrán en ejecución paralelamente parte de la codificación y de las pruebas. Además del hecho de que puedan darse retroalimentación entre la codificación, la prueba y la eliminación de las fallas.
8 Los diseñadores tenían poco contacto co n el analista que escribía la especificación y definitivamente no tenían contacto con el usuario.
Ciclo de vida del proyecto estructurado: Se divide en 9 actividades:
Necesidad
Usuario
Encuesta 1
Documento
Análisis 2
Especificación Estructurada
Diseño 3
Conversión de BD 8
Especificación Estructurada
Generación de pruebas de aceptación 5 Datos
Descripción de Procedimientos 7 Manuales
Control de Calidad 6
Implantación 4
Sistemas Programados
Sistema Aceptado
Instalación 9
La encuesta: conocido también como el estudio de la factibilidad. Empieza cuando el usuario solicita que una o mas partes de su sistema se automatice. Objetivos: Identificar a los usuarios solicitantes del pedido y crear un ámbito de trabajo con ellos. Identificar las deficiencias actuales en el ambiente del usuario como pueden ser el software del sistema actual no se puede mantener o el tiempo de respuesta del sistema telefónico es malo Establecer metas y objetivos para un nuevos sistema. Determinar si es factible automatizar el sistema y de ser así sugerir escenarios aceptables. Preparar el esquema de guía que se usara para el resto del proyecto
Si bien la encuesta solo toma entre el 5% y 10% del tiempo total del proyecto, es una actividad fundamental y verdaderamente importante.
Análisis de sistemas: Su función es transformar sus dos entradas (las políticas del usuario y el esquema de guía del proyecto) en una especificaciones estructurada. Esto implica el desarrollo de un modelo ambiental
9 y el desarrollo de un modelo de comportamiento. Estos dos modelos se combinan para formar el modelo esencial, que representan una descripción formal de lo que el nuevo sistema debe hacer. El diseño: partiendo de la especificaciones estructurada, se ocupa de transformar los modelos de datos de entidad-relación en un diseño de base de datos. Implantación: Es el paso en donde los programadores se ponen a trabajar, incluye tanto programación estructurada como implantación descendente. El analista no se vera involucrado en esta actividad. Generación de pruebas de aceptación: Generar lo s datos de prueba. Puede darse al mismo tiempo que las actividades de diseño e implantación, pudiera ser que al analista le sea asignada esta labor al término del desarrollo del modelo esencial. Garantía de calidad: También conocida como prueba final o la prueba de aceptación. Requiere como entrada los datos de la prueba de aceptación generada en la actividad anterior y el sistema integrado producido en la implantación. El analista puede estar involucrado pero por lo general no lo esta. Se busca que el sistema tenga un nivel apropiado de calidad. Descripción del procedimiento: Generación de una descripción formal de las partes del sistema que se harán en forma manual, lo mismo que la descripción de cómo interactuaran lo usuarios con la parte automatizada del nuevo sistema. El resultado de este paso es el “manual para el usuario”. El Analista podría verse involucrado. Conversión de Base de Datos: Por lo común, esta actividad requiere como entrada la base de datos actual del usuario. Instalación: La entrada se basa en el manual del usuario, la base de datos convertida, y el sistema aceptado producido por la garantía de calidad.
Implantación Radical VS Implantación Descendente:
La vida del proyecto estructurado permite que más de una actividad se lleve a cabo a la vez. Es decir que ambos extremos se podrían detallar así: Implantación radical: Las actividades de la 1 a la 9 se llevan a cabo paralelamente desde el principio del proyecto. Implantación Descendente: es un enfoque mas conservador la actividad N completa se termina antes de comenzar con la actividad N + 1. Obviamente son extremos, en medio existen infinidad de matices que nos dan infinitos numero de opciones y posibilidades para implementar en un proyecto. El problema surge cuando uno tiene que decidir cual va a ser su enfoque. Existen varios casos a tener en cuenta. En primer lugar esta el Usuario, si constamos con un usuario altamente indeciso o poco experimentado lo mejor será optar por un enfoque mas radical y poder cumplir con los requisitos lo antes posible antes de que el usuario cambie de opinión o pretenda cambiar la función del sistema. En cambio si contamos con un usuario que sabe exactamente lo que quiere y tiene experiencia en el ámbito, la mejor opción será trabajar con un enfoque más conservador. Otro factor importante es el de la presión, si el equipo desarrollador cuenta con una fecha limite en donde forzosamente debe entregar el sistema lo mejor será un enfoque radical para poder llegar a cumplir con esa fecha en la forma mas exacta posible. En cambio si no contamos con una fecha próxima/tiránica (tener
10 en cuenta que todos los proyectos cuentan con una fecha de entrega) se puede trabajar más holgadamente con un enfoque más conservador. También a tener en cuenta esta el hecho de la presentación de estimaciones, programas y presupuestos. De tratarse es un emprendimiento menor en el cual estas presentaciones son “mera formalidades” se deberá trabajar con es de suponer con un enfoque mas radical de manera de terminar lo antes posible con el trabajo. En cambio si el nivel de detalle y presentaciones es elevado esto será directamente proporcional a la conservador que deberá ser el enfoque. Por ultimo el administrador del proyecto debe considerar la posibilidad de cometer un error técnico importante. Siempre existe la posibilidad de describir un error a último momento. En resumen, de presentarse un proyecto chico en el cual nadie esta muy seguro de lo que quiere o de cómo hacerlo, la solución seria realizar un proyectó cuyo ciclo de vida tenga implantación lo mas radical posible. En cambio si se trata de un proyecto grande, con mucha inversión de capitales, la opción mas acertada seria hacer un ciclo de vida del proyecto estructurado con l a implementación lo mas descendente posible.
Ciclo de vida de Prototipo: variación del ciclo de vida estructurado descendente. La principal diferencia es que el enfoque descendente construye un modelo en papel completo del sistema, en cambio el de prototipo crea un modelo de lo que seria el sistema finalizado con la intención de ser un prueba y muestra para el usuario. Que el lo vea, y decida si es lo que quiero o no y su cumple con los queriditos pedidos por el. Es especial para aquellos casos en que: El usuario no puede o no esta dispuesto a examinar modelos abstractos en papel. El usuario no puede o no esta dispuesto a decirnos los requisitos y solo se puede determinar mediante tanteo o ensayos de prueba y error. Cuando se tiene la intención de que el sistema sea en línea y con operaciones total por pantalla. El sistema no requiere de grandes especificaciones de detalles.
Modelos
Ventajas de un modelo: Sirve para concentrarse en las partes importantes del sistema Discutir cambios a bajo costo y mínimo riesgo Verificamos correcta comprensión y le entregamos i nformación a los diseñadores y programadores necesaria para realizar el sistema. Características de los modelos: Redundancia mínima de información Capacidad de desglosar el sistema de lo macro a lo micro. Fácil mantenimiento Fácil de entender para alguien sin conocimientos de sistemas
Modelo esencial Definición, objetivos y características
Modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario tr atando de describir lo menos posible acerca de la implementación. Sirve para dar una 1° idea de lo que el sistema es o se pretende.
Enfoque clásico
Partiendo del sistema actual, se trataba de llegar al nuevo. Se separaba en 4 modelos:
11
Físico actual: Modelo funcional (DFD) o físico del sistema actual. Las burbujas muestran entidades organizacionales, personas o funciones y los flujos de datos muestran formas de transporte de la información de entre las burbujas. Lógico actual: Modela los requerimientos que realiza el sistema actual. Lógico nuevo: Modela los requerimientos que debe realizar el sistema nuevo. Físico nuevo: Modela las limitaciones de implantación impuestas por el usuario como la frontera de automatización. Se perdía mucho tiempo en análisis del sistema viejo que después se desechaba en su mayoría.
Componentes
Modelo ambiental Modelo de comportamiento: Describe el comportamiento que el sistema tendrá para interactuar de manera exitosa con el ambiente.
Modelo ambiental Definición, objetivos y características
Define la frontera entre el sistema y el resto del mundo o ambiente en el cual el sistema existe. Determina qué es parte del sistema y que no. Todo sistema es parte de un subsistema. El interior es llamado dominio de cambio. Modela el exterior del sistema. Determina qué información entra (estímulos) y qué información se va (respuestas). Debido a que construimos sistemas racionales, las respuestas son una reacción ante los estímulos. Sin embargo no todos los estímulos deben tener una reacción asociada, no todos los estímulos nos preocupan o interesan, solo los que requieran una respuesta.
Componentes
Declaración de objetivos. Diagrama de contexto. Lista de acontecimientos.
Declaración de objetivos Definición, objetivos, características y consejos de construcción
Declaración textual y breve de los propósitos del sistema. Dirigida a niveles administrativos. No es una descripción detallada, sino un resumen, un pantallaso, vaga en detalles. Nunca más de 1 párrafo. Algunos piensan que tiene que explicitar los beneficios tangibles y cuantificables que se logren con el sistema. útil en proyectos chicos.
Diagrama de contexto. Definición, objetivos, características y consejos de construcción
Modeliza la frontera e interacción del sistema con el exterior. Caso especial del DFD donde 1 sola burbuja representa todo el sistema. Describe terminadores con los que se comunica. Los terminadores pueden o no comunicarse entre si pero al ser externos al sistema esto le es irrelevante al mismo. Si resulta relevante entonces estos deben incluirse. Distinguir entre fuentes y manejadores. Describe flujos de datos que intercambia con ellos (tanto recibe como envía). Evitar mostrar mecanismos de coordinación (del tipo "estoy listo para recibir") excepto cuando sean esenciales. Podrían interpretarse como implementación. Describe los almacenes que el sistema comparte con los terminadores.
12 Lista de acontecimientos Definición, objetivos, características y consejos de construcción
Lista de los estímulos a los cuales el sistema responde. Cada estimulo debe producir respuestas, almacenar datos u o casionar cambio en el estado del sistema. Describe acontecimientos desde el punto de vista del ambiente, desde afuera. Para identificar mejor acontecimientos investigar efectos de acciones de cada terminador sobre el sistema. Tener en cuenta situaciones de falla de los terminadores, como acciona el terminador y la reacción del sistema.
Modelo de comportamiento
Modela el comportamiento que debe tener el sistema para realizar con éxito sus tareas.
Componentes
DFD Especificaciones de procesos. DER Diccionario de datos.
DFD Definición, objetivo y características
Modela los procesos que lleva a cabo un sistema. Modela aspecto funcional. Permite visualizar un sistema como una red de procesos funcionales conectados mediante flujos y almacenamientos de datos. Cabe en 1 página Fácil visualización. No requiere explicación por su fácil interpretación Bueno para el usuario. No es puramente descendente, sino que se asciende y desciende según etapas.
Enfoque clásico
Partiendo del diagrama de contexto, se desciende hasta el nivel 0 o superior donde se ve al sistema como un conjunto de subsistemas, representados por burbujas. Luego se explota cada burbuja hasta el nivel de una burbuja atómica donde no se requiera mayor descomposición. No es malo, pero presenta problemas: Parálisis del análisis: En sistemas grandes es difícil construir el nivel 0 desde el diagrama. de contexto. No hay indicios de ayuda. Se pierde tiempo esperando inspiración. Fenómeno de los 6 analistas: En sistemas grandes, con varios analistas involucrados, se crea 1 burbuja para cada uno de modo de no estorbarse. No siempre es la mejor partición. Si hubiese más analistas, se haría la misma partición? Partición física arbitraria: Se toman como parámetros de partición unidades organizativas (ej.), olvidando la visión funcional, pudiendo no ser la mejor manera.
Componentes
Proceso: Parte del sistema que transforma datos de entrada en datos de salida. Flujo: Describe movimiento de información entre componentes del sistema. Representa datos en movimiento. Diálogo: Flujos que empacan una pregunta y respuesta en el mismo flujo. Almacenes: Modelizan colección de datos en reposo. Físicamente puede ser un archivo, una cinta, una tarjeta perforada… Puede existir como requerimiento fundamental del usuario (sincronización o comunicación entre 2 procesos no sincronizados) o conveniencia del sistema. El almacén es pasivo. Los datos viajan a través del flujo porque el proceso lo solicita. Lectura no destructiva: Por convenio no se modifica un almacén cuando se lo lee, se recupera copia. Terminadores: Entidades externas con las cuales el sistema se comunica.
13
Están fuera del control del sistema que esta modelando. Los flujos que conectan a los terminadores con el sistema son la interfaz. No se muestran las relaciones que existen entre los terminadores. Consejos para la construcción
Evitar sumideros infinitos, burbujas que tienen entrada pero no salidas. Evitar burbujas de generación espontánea, tienen salidas pero no entrada. Cuidado con flujos y procesos no etiquetados. Revisar que algo no halla sido olvidado. Cuidado con almacenes de solo lectura o solo escritura. Si nadie lo actualiza, esta v ació. Si nadie lo lee, no tiene sentido su existencia. La excepción son los almacenes externos que sirven como interfaz entre sistema y entidad externa. Puede ser que 1 proceso necesite flujos de entrada de otros terminadores (sin ser acontecimientos) para realizar su tarea. Existen acontecimientos que causan múltiples respuestas (todas las respuestas son independientes y usan igual flujo de entrada) y acontecimientos múltiples que causen igual respuesta (flujos de entradas y salida y respuesta son siempre iguales para todos los acontecimientos). Los procesos no se comunican entre si, sino a través de almacenes, porque los acontecimientos no son necesariamente sincronizados, ocurren en ambiente externo no controlado por nosotros. Métodos para armado de nivel 0 a partir de DFD preliminar: Datos relacionados: Cada agrupación involucra respuestas relacionadas cercanas. Almacenes locales: Se busca enterrar los almacenes de forma que solo los procesos de la agrupación haga uso de los almacenes locales enterrados. Capacidad de visualización: Regla de miller (7 +/- 2). Métodos para descomposición: Secuencia de sub-tareas. Procesar entradas, combinar, componer salidas.
Organización en niveles
Permite ver mejor la información. Dá más detalle sobre porciones del nivel anterior. Se usa sistema de numeración para relacionar diagramas de distintos niveles. Diagrama de contexto: 1 sola burbuja representando el sistema completo. Muestra la relación entre sistema y el ambiente que lo rodea. DFD 0: Vista de más alto nivel con las principales funciones e interfaces del sistema. DFD 1: 1 por cada proceso del DFD 0. describiendo el proceso en cuestión. DFD N: Muestran en mas detalle el desarrollo de porciones de un proceso.
Observaciones de la organización en niveles
Debe haber los niveles necesarios para describir las primitivas de forma simple. No todas las burbujas deben tener el mismo nivel de detalle. Depende de l a complejidad. Los flujos que salen y entran de una burbuja a nivel N deben ser iguales a los que salen y entran de todo el nivel N + 1 correspondiente. Los almacenes que se muestran en un nivel deben conectar burbujas. Sino los son, son locales y están incluidas implícitamente en un nivel i nferior.
DER Definición, objetivo y características
Modelo aspecto de datos del sistema. Es modelo de red que describe la distribución de los datos almacenados. Para poder resolver situaciones con estructuras de datos y relaciones complejas. No es necesario que todos los tipos de objeto estén conectados entre sí.
Componentes
Tipo de objeto: Conjunto de datos del mundo real.
14
Los tipos de objeto representan en el sistema algún objeto del mundo real. Tienen instancias (miembros individuales) que Pueden identificarse de manera univoca. Son necesarios para el sistema. Pueden describirse por 1 o más datos o atributos. relación: Conexiones entre objetos. Puede existir más de 1 relación entre 2 objetos. Puede haber más de 2 objetos en una relación. Tienen instancia que representan una asociación entre 0 o más ocurrencias de un objeto con 0 o más ocurrencias de otro objeto. La cardinalidad describe cuantas instancias de un objeto hay en cada instancia de la relación. Tipo de objeto asociativo: relación de la cual se quiere mantener información. Funciona como objeto y como relación. Subtipo / Supertipo: Sirven para mostrar distintas categorías de tipos de objeto. Los datos del supertipo aplican a todos los subtipos. Cada subtipo se describe por datos diferentes del otro.
Modelo de Datos
Serie de conceptos que puede utilizarse para describir un conjunto de datos y operaciones para manipular los mismos.
Fase conceptual: parte de la especificacion de requerimientos de los usuarios y finaliza con un esquema conceptual a un alto nivel de abstracción de los datos y relaciones que se establecen dentro del sistema. Fase lógica: parte del esquema conceptual al esquema lógico. Descripción de la estructura que deben tener los datos y las relaciones de los datos para ser procesados por una computadora. Fase física: parte del esquema lógico . Describe la estructura de almacenamiento y los métodos usados para acceder a los datos.
Modelo jerárquico: Cada hijo tiene un solo padre (entidad) Modelo de Red: Multiherencia. Modelo relacional: Grilla Abstracción: proceso mental que se aplica al seleccionar algunas características y propiedades de un conjunto de objetos y excluir otras. Tipos de Abstracción: Clasificación: Tratar de obtener clases. Deriva de otras que tiene características comunes y las 3 son necesarias. (Miembro de).(línea punteada) Abstracción: Define una nueva clase a partir de un conjunto de otras clases que representan sus partes componentes. (Es parte de)(doble línea) Generalización: Define una relación de subconjunto entre los elementos de dos o mas clases. (Es un).(línea simple)
