ESCUELA DE INGENIERÍA DE SISTEMAS Y SEGURIDAD INFORMÁTICA.

Transcripción

1 ESCUELA DE INGENIERÍA DE SISTEMAS Y SEGURIDAD INFORMÁTICA SESION William León Velásquez

2 MODELO DE DIAGRAMA DE DATOS Los modelos basados en diagramas de datos o diagramas de flujos de datos, permiten la representación del ámbito de la información y el ámbito funcional al mismo tiempo.

3 MODELO DIAGRAMA DE CONTEXTO El objeto de un diagrama de contexto es mostrar gráficamente un medio ambiente y las entradas y salidas de un Sistema de Información. Es utilizado durante la fase de conceptualización.

4 MODELO DIAGRAMA DE CONTEXTO El medio ambiente es mostrado a través de Entidades Externas que representan: personas físicas o jurídicas, empresas, otros sistemas, etc. En general entidades que pueden generar y/o recibir información del SI. Mientras que las entradas y salidas son representadas por el flujo de datos.

5 MODELO DE DATOS Indica un sistema de Información, por su nombre. Sistema XYZ Indica entidad externa por su nombre Indica una dirección de flujo en el Sentidodelaflecha de flecha. Nombre Entidad Externa

6 MODELO DE ESTRUCTURA DE DATOS LAS CARTAS DE N-S o DIAGRAMAS ESTRUCTURADOS

7 MODELO DE ESTRUCTURA DE Ejercicio: 1. Se desea obtener la nomina semanal salario-neto de los empleados de una DATOS empresa cuyo trabajo se paga por horas en la siguiente i forma: Las horas inferiores a 35 horas (normales) se pagan a una tarifa determinada que debe ser ingresada, al igual que los datos del trabajador. Las horas iguales o superiores a 35 se pagarán como extras a un precio de 1.5 horas normales. Los impuestos a deducird a los trabajadores varían en función de su sueldo mensual : Sueldo < = S/.200 libre de impuestos. Los siguientes S/.150 al 20%, el resto al 30%.

8 MODELO DE ESTRUCTURA DE DATOS

9 DIAGRAMA DE FLUJO Es una herramienta especializada para representar algoritmos mediante el uso de figuras, las cuales se unen mediante flechas denominadas líneas de flujo que indican el orden en que se deben ejecutar. MODELO DE ESTRUCTURA DE DATOS

10 Elementos de la Diagramación MODELO DE ESTRUCTURA DE DATOS

11 Elementos de la Diagramación MODELO DE ESTRUCTURA DE DATOS

12 Elementos de la Diagramación MODELO DE ESTRUCTURA DE DATOS

13 Elementos de la Diagramación MODELO DE ESTRUCTURA DE DATOS

14 MODELO DE FLUJO DE DATOS Los modelos basados en el flujo de datos, establecen la representación relacionada al ámbito de la información y su funcionalidad d a un mayor detalle. Especifican los flujos entre las entidades y los procesos así como su almacenamiento.

15 MODELO DE FLUJO DE DATOS Entidad Proceso Almacenamiento

16 MODELO DE FLUJO Un diagrama o modelo DE DATOS entidad-relación (a veces denominado por su siglas, E-R "Entity relationship", o, "DER" Diagrama de Entidad Relación) es una herramienta para el modelado de datos de un sistema de información. Estos modelos expresan entidades relevantes para un sistema de información, sus inter-relaciones y propiedades

17 El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de bases de datos. Fue introducido por Peter Chen en El modelo entidad-relación está formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones gráficas y lingüísticas. MODELO DE FLUJO DE DATOS

18 Entidad MODELO DE FLUJO Cualquier tipo de objeto o DE DATOS concepto sobre el que se recoge información: cosa, persona, concepto abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes, empresas, oficios, diseños de productos, conciertos, excursiones, etc. Las entidades se representan gráficamente mediante rectángulos y su nombre aparece en el interior. Un nombre de entidad sólo puede aparecer una vez en el esquema conceptual.

19 Atributo t Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los atributos representan las propiedades básicas de las entidades y de las relaciones. Toda la información extensiva es portada por los atributos. Gráficamente, se representan mediante bolitas que cuelgan de las entidades o relaciones a las que pertenecen. MODELO DE FLUJO DE DATOS

20 Relación (interrelación) Es una correspondencia c o asociación entre dos o más entidades. Cada relación tiene un nombre que describe su función. Las relaciones se representan gráficamente mediante rombos y su nombre aparece en el interior. MODELO DE FLUJO DE DATOS

21 MODELO DE FLUJO DE DATOS

22 El lenguaje de modelado es la notación (principalmente p gráfica) que usan los métodos para expresar un diseño. El proceso indica los pasos que se deben seguir para llegar aun diseño. UML

23 UML Desarrollo Basado en equipo Lenguaje de Proceso Caso de Uso modelamiento Unificado Use-Case Modelo Objeto

24 ELEMENTOS DEL MODELO DE DATOS Estilo de programación & modelo Cada programador tiene un estilo de programación definido por el lenguaje, por ejemplo: Orientado a Procedimientos Algoritmos Orientado a Objetos Clases y objetos Cada estilo está basado en un modelo, en el caso de los modelos OO es el Modelo objeto

25 Modelar la interfaz hombre - máquina, establece que en la creación de un sistema, se desarrolla un modelo de diseño y un modelo de usuario. MODELO DISEÑO DE INTERFACES El usuario final desarrolla una imagen mental de como quiere que sea el sistema, el cual puede diferir con el modelo del diseño propuesto por el analista.

26 El diseño de interfaz, consiste en reconciliar estas diferencias y generar una representación consistente. MODELO DISEÑO DE INTERFACES El modelo de usuario representa el perfil de los usuarios finales, por lo que para construir una interfaz efectiva, el diseño debe empezar con un conocimiento de los posibles usuarios (Perfiles sobre: su conocimiento, educación, personalidad, procedencia cultural, religión etc..)

27 Es una representación simplificada que permite establecer el sistema de información que requiere la organizaciónenfuncióndeun conocimiento del modelo del negocio. Las reglas del Negocio Procesos necesarios para ejecutar funciones Bases de Datos MODELO DE INFORMACIÓN

28 Este modelo constituye el paradigma del ciclo de vida clásico de los sistemas, el cual exige un enfoque sistemático y funcional del desarrollo de sistema. Este ciclo abarca las actividades. MODELO EN CASCADA Ingeniería del sistema Analísis Diseño Codificación Prueba Mantenimiento

29 MODELO LINEAL SECUENCIAL O CASCADA Ingeniería de Sistemas/Información Análisis Diseño Código Prueba

30 Ingeniería y Análisis del Sistema Debido a que el sistema es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema MODELO EN CASCADA

31 Diseño Es un proceso que emprende varias actividades y se enfoca CASCADA sobre: - La estructura de los datos - Arquitectura del software - Detalle procedimental - Interfaz El proceso de diseño traduce los requisitos de una representación del software que puede ser establecida de forma que se obtenga la calidad d requerida antes de iniciar la codificación. MODELO EN

32 MODELO EN Codificación ió CASCADA El diseño debe traducir en una forma que sea legible para el computador. El paso de codificación realiza esta tarea. Así si el diseño se realiza en una forma detallada, la codificación puede realizarse mecánicamente.

33 Prueba Una vez generado el código, comienza la prueba del programa, el cual se centra en la lógica interna del software, asegurando que todas las sentencias se han probado, asegurando que la entrada definida produce los resultados que realmente se requieren MODELO EN CASCADA

34 Mantenimiento MODELO EN CASCADA El software, indudablemente sufrirá los cambios en su vida operativa, debido a que tiene que adaptarse a cambios en su entorno o por las ampliaciones funcionales o de rendimiento que soliciten los usuarios.

35 MODELO EN El ciclo de vida clásico o modelo CASCADA en cascada es el paradigma más antiguo y más ampliamente usado en la Ingeniería de Software. Sin embargo en el transcurrir de los años se han producido criticas a su aplicabilidad: Los proyectos raramente siguen el flujo secuencial que propone el modelo. Siempre hay alteraciones y se crea problemas en la aplicación del paradigma.

36 MODELO EN Es difícil para el cliente CASCADA establecer explícitamente al principiop todos los requisitos. Existen dificultades en acomodar posibles incertidumbres que pueden existir al inicioi i del proyecto. El cliente debe tener paciencia. Hasta llegar a las etapas finales del desarrollo del proyecto no estará disponible una versión operativa del programa. Por lo que un error importante no detectado hasta que el programa este operativo puede ser desastroso.

37 MODELO EN CASCADA A pesar de estos problemas el paradigma clásico de vida son muy similares a los pasos genéricos aplicables a todos los paradigmas del desarrollo de software y es uno de los más usados a pesar de sus inconvenientes.

38 El modelo en espiral utilizado para la creación de software emplea un enfoque evolutivo en una dimensión ió radial ( comenzando en el centro y avanzando hacia el exterior). Este modelo define cuatro actividades principales, representadas en cuatro cuadrantes: Planificación; Determinación objetivos, alternativas y restricciones. Análisis de Riesgo; Análisis de alternativas e identificación o resolución del riesgo. MODELO EN ESPIRAL

39 Ingeniería; Desarrollo del producto al siguiente nivel. Evaluación del Cliente; Valorización de los resultados de la Ingeniería. MODELO EN ESPIRAL

40 Comunicación con el cliente Punto de entrada al Proyecto Evaluación del cliente Planificación MODELO ESPIRAL (BOEHM) Análisis de riesgos A B C D Construcción y adaptación Ingeniería A: Desarrollo de Conceptos B: Desarrollo de Productos C: Mejora de Productos D: Mantenimiento de Productos

41 Comunicación con el cliente Planificación Evaluación del cliente Análisis de riesgos Construcción y adaptación (ingeniería) MODELO DE ENSAMBLAJE DE COMPONENTES Identificar componentes candidatos Construir n interacciones del sistema Poner componentes nuevos en la biblioteca Buscar componentes en Biblioteca Extraer componentes si están disponibles Construir componentes si no están disponibles

42 Es un proceso que facilita la creación de un modelo de software, el cual es evaluado por el cliente/usuario para refinar los requisitos del software a desarrollar. Se produce un proceso interactivo en el que el prototipo es afinado para satisfacer las necesidades del cliente, al mismo tiempo que facilita al que lo desarrolla una mayor composicióndeloquehayque hacer. MODELO DE PROTOTIPOS

43 Construír y Revisar Maqueta MODELO DE PROTOTIPOS Escuchar al Cliente El cliente prueba la maqueta

44 Inicio i Parada Producto de Ingenieríag Refinamiento prototipo Recolección y refinamiento i de requisitos Diseño rápido Evaluación del prototipo por el Cliente Construcción prototipo MODELO DE PROTOTIPOS

45 MODELO DE PROTOTIPOS Trabajar con módulos manejables Modularidad Construir el Prototipo con rapidez Modificar el Prototipo una vez revisado por los usuarios Enfatizar la Interfaz con el Usuario Menor Tiempo (1 semana/3 días) Baja dependencia de los módulos Amigables y en relación al modelo de usuario

46 Ventajas del prototipo MODELO DE PROTOTIPOS Modificación rápida del sistema en su desarrollo Oportunidad de detener el desarrollo de un sistema que no es útil. Posibilidad de desarrollar otro sistema que se ajuste mejor a las necesidades y a las expectativas del usuario.

47 MODELO DE L i l li t d PROTOTIPOS Desventajas Los usuarios como los analistas pueden considerar el prototipo como un sistema concluido, cuando de hecho no lo es y nunca se planteo como un sistema final. Los usuarios pueden llegar a crear patrones de relación con el sistema prototipo que no son compatibles con el sistema propuesto. Un prototipo puede no realizar todas las funciones requeridas. Eventualmente cuando surgen las deficiencias, el prototipo p semenospreciará si fue adoptado equívocamente como un sistema completo.

48 MODELO DRA Desarrollo Aplicaciones i Rápidas Consiste en brindar soluciones de desarrollo de aplicaciones específicas para cada necesidad, mediante un proceso de construcción de software que permite desarrollar sistemas productivos en muy poco tiempo.

49 MODELO DRA Desarrollo Aplicaciones i Rápidas Equipo # 1 Equipo # 2 Equipo # 3 Modelado de gestión Modelado de datos Modelado de procesos Modelado de gestión Generación de aplicaciones Modelado de datos Pruebas y volumen Modelado de procesos Modelado de gestión Generación de aplicaciones De 60 a 90 días Modelado de datos Pruebas y volumen Modelado de procesos Generación de aplicaciones Modelado de gestión

50 MODELO INCREMENTAL En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o "Pipeline", utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente.

51 MODELO INCREMENTAL Ingeniería de Sistemas/Información Análisis Diseño Código Pruebas Incremento 1 Incremento 2 Análisis i Diseño Código Pruebas Incremento 3 Análisis Diseño Código Pruebas Tiempo de calendario

52 MODELO DE Diseño de Salidas del Sistema ENTRADA Y SALIDA La salida, es la información que reciben los usuarios del sistema de información, con el fin de crear una salida de utilidad. El analista de sistemas trabaja estrechamente t conel usuario mediante un proceso interactivo, hasta que el resultado llegue a ser satisfactorio. Puesto que una salida útil es esencial para a lograr la aceptación y el uso del sistema de información. El sistema debe alcanzar los objetivos:

53 Elección efectiva del método de salida Asegurar una salida úil MODELO DE ENTRADA Y SALIDA Con significado para el usuario Asegurar la oportunidad Diseño Con un Volúmen Con una distribución adecuada

54 MODELO DE SALIDA / ENTRADAS Diseño de Entradas al Sistema La calidad de la salida del sistema está determinada por la calidad de su acceso o entrada. Un buen diseño de las entradas permitirá obtener una información adecuada que requieran los usuarios. Entradas pobres pondrán en entredicho la calidad del sistema, por lo que se consideran los siguientes objetivos:

55 MODELO DE SALIDA / ENTRADAS Eficacia Facilidad d de Uso Precisión Diseño Consistencia y Validación Sencillez Atracción

56 FIN