• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Significado dentro del ciclo de vida de desarrollo de sistemas
 

Significado dentro del ciclo de vida de desarrollo de sistemas

on

  • 2,177 views

Unidad I. Diseño de Sistemas. Significado dentro del Ciclo de Vida de Desarrollo de Sistemas. Modelos de Desarrollo de Software. Modelos de Desarrollo Estructurado. Sommerville, 8.5 y 4.5.1. ISI ...

Unidad I. Diseño de Sistemas. Significado dentro del Ciclo de Vida de Desarrollo de Sistemas. Modelos de Desarrollo de Software. Modelos de Desarrollo Estructurado. Sommerville, 8.5 y 4.5.1. ISI (3K1) UTN-FRT (2011)

Statistics

Views

Total Views
2,177
Views on SlideShare
2,177
Embed Views
0

Actions

Likes
0
Downloads
41
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Significado dentro del ciclo de vida de desarrollo de sistemas Significado dentro del ciclo de vida de desarrollo de sistemas Presentation Transcript

    • Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
    • Contenidos de la Unidad 1 Introducción al Diseño
      • Significado Dentro del Ciclo de Vida de Desarrollo de Sistemas.
        b. Modelos de Desarrollo de software  
          • Modelos de Desarrollo Estructurado
      Sommerville. Sección 8.5 y 4.5.1 Pressman. Sección 2.10
            • Modelo en Cascada.
      Sommervillle. Sección 4.1.1. Pressman. Sección 2.4.
            • 2. Modelos evolutivos: incremental y espiral.
      Sommervillle. Sección 4.1.2. Pressman. Sección 2.7
            • 3. RUP
      Sommervillle. Sección 4.4. Jacobson, Booch y Rounbahg. Secciones 1.1 a a 1.5. Larman últ. Ed. Sección 37.1., 37.4 y 37.9
      • Diseño Estructurado: Primera aproximación científica para «atacar la Complejidad»  
      • I – La Complejidad:
      • A) Sistemas de Software Simples Vs. Complejos (de dimensión industrial).
      • B) Complejidad inherente al software.
      Unidad I: Significado dentro del Ciclo de Vida de Desarrollo de Sistemas
      • Caracteres del Software de dimensión industrial:
      • Difícil entender todos los aspectos de su diseño.
      • Su complejidad excede la capacidad intelectual humana.
      • Grandes sistemas: la complejidad es su propiedad esencial.
      • Esencial: La complejidad puede dominarse. Nunca eliminarse.
      A) Software Simple Vs. Software Complejo
      • Deriva de 4 elementos:
      • a) Dominar el Problema .
      • b) Desarrollar el Soft: Escribir y Reutilizar. Equipo de desarrolladores: Comunicación y Coordinación. Dispersión geográfica. Proyectos grandes.
      • c) Flexibilidad propia del Soft: el desarrollador tiende a autoabastecerse de todo.
      • d) Comportamiento de los Sistemas Discretos: Sistemas continuos: leyes físicas y determinísticos. Grandes sistemas discretos: explosión combinatoria de posibilidades. Eventos externos pueden corromper el estado del sistema.
      B) Complejidad inherente al software
    • II – El Análisis: Imponer Orden al Caos: La Descomposición: Técnica de dominar la complejidad: “divide et impera” (Dijkstra) B) El Análisis: Proceso que define los requerimientos para solucionar un problema Examina las necesidades del usuario Define las propiedades que debería poseer el sistema para cubrir esas necesidades Identifica las limitaciones del sistema y los requisitos de performance Define precisamente las funciones a llevarse a cabo y no cómo trabajan Del análisis surgen las ESPECIFICACIONES FUNCIONALES DEL SISTEMA. Deseo de saltear el Análisis: común, ya que carece de herramientas técnicas y metodología como en el diseño Se orienta más a las personas que a los equipos. Enfoca la interfaces usuario/computadora Los desarrolladores siempre prefieren ignorar esta interfaces a favor de los asuntos técnicos más fácilmente definibles Análisis: Define los requerimientos del problema y propone una solución Primero se determinan las partes del problema y sus interrelaciones Es esencial entender completamente el problema antes de definir una solución
    • El Análisis Si la estructura de la solución no refleja la estructura del problema, el sistema resultante será difícil de cambiar y mantener El no anticipar la natural tendencia de los sistemas al cambio fue la causa de la construcción de software inflexible, caro e inmantenible Sólo luego de entender bien a un problema, puede proponerse una buena solución Los problemas no son estáticos: pueden cambiar en el futuro, en función de un usuario determinado, del tiempo y nuevas tecnologías El ANALISIS influye enormemente en el resto del ciclo de vida del sistema
    • Especificaciones Funcionales del Sistema Resulta de la fase de ANALISIS Describe cómo el sistema deberá satisfacer los requerimientos del problema Define: reportes, estructuras de datos, bases de datos, archivos externos, tablas internas, componentes funcionales e interfaces con otros sistemas. O sea: componentes del sistema e interfaces que los conectan Ofrece al usuario y desarrollador una descripción concreta de los componentes para evitar confusiones del usuario y errores del desarrollador Debe ser precisa, comprobable y formal. Entendible por analistas, diseñadores y usuarios. Es el medio de comunicación principal entre ellos Unas especificaciones completas y correctas afectan el éxito de todo el esfuerzo de desarrollo Influye en proyectar tiempos, asignar personal, documentación, plan de pruebas Mala especificación: demoras, malas pruebas, documentación incorrecta. Resultado: soft no confiable ni útil Errores de especificación: muy caros (100 veces más) si no se detectan y corrigen tempranamente
    • III – El Diseño: A) Conceptos Generales: Etapa que sigue al Análisis antes de la Implementación Proceso de planificar cómo se construirá el sistema Determina los procesos y datos que se necesitan Ensambla dichos componentes para proporcionar la solución informática Desarrollo de algoritmos que describen lo que hace cada componente Input del Diseño: Especificaciones Funcionales, Requerimientos y Limitaciones del Problema proporcionados por el ANALISIS. Detectar 1 error de diseño durante la codificación requiere el doble corregirlo. Detectarlo durante la fase de prueba, 10 veces más Mayor cuidado al diseño = > Sistemas más baratos y confiables
    • El Diseño: Conceptos Generales Base de la implementación del sistema, ayuda la lectura y confiabilidad del soft, reduce su complejidad y costo Subestimada en el desarrollo tradicional de sistemas. Se saltea en muchos desarrollos. Esto ocasiona problemas y consecuencias a largo plazo Su falta complica el desarrollo, que carece de plan de acción. Dificulta asignar personal a las tareas. No hay mecanismos de medición de la calidad de los trabajos de los desarrolladores. Carece de documentación y prueba Oportunidad dada a los desarrolladores para planear lo que van a hacer y evaluar las bondades de su plan antes de codificarlo y probarlo Propósito: Especifica cómo debe ser construido el software para cumplir con las Especificaciones Funcionales
      • 1º) Diseño Arquitectónico o del Sistema:
      • 2º) Diseño Detallado:
      B) Etapas del Diseño:
    • 1º) Diseño Arquitectónico o del Sistema Diseño de Alto Nivel Define los procedimientos básicos y sus interrelaciones Define a grandes rasgos la representación de los datos Sigue la estructura del problema a resolver
    • 2º) Diseño Detallado Crea algoritmos específicos Estructuras de Datos detalladas. Define niveles del sistema Requiere niveles sucesivos de detalle y refinamiento Termina con algoritmos precisos y estructuras de datos que cubren todos los requerimientos
    • C) Métodos del Diseño Conceptos Generales. Importancia: Camino para llegar a un fin Proceso disciplinado para generar un conjunto de modelos que describe a un sistema de software en desarrollo, utilizando alguna notación bien definida Brindan disciplina para desarrollar sistemas de software complejos Facilitan comunicación y estándares en equipos de desarrollo Definen metas y objetivos para medir el progreso y gestionar el riesgo Surgieron de la complejidad creciente de los sistemas de software: 60’s y 70’s
      • 1º) Metodologías de Diseño Estructurado o Diseño Compuesto.
      • 2º) Metodologías de Diseño Dirigido a los Datos.
      • 3º) Diseño Orientado a Objetos.
      Clasificación de las Metodologías de Diseño de Sistemas:
    • 1º) Metodologías de Diseño Estructurado o Diseño Compuesto Fueron los métodos más utilizados hasta los ‘90 Influencia de lenguajes: FORTRAN y COBOL Unidad fundamental de Descomposición: Subprogramas Programa resultante: árbol donde subprogramas se ejecutan llamando a otros subprogramas Aplica la descomposición algorítmica para fragmentar un problema grande en pasos más chicos Fundamentos Teóricos: Yourdon, Wirth, Dijkstra, Mills
    • Metodologías de Diseño Estructurado o Diseño Compuesto Usa el concepto de modularización, restringe las interfases entre módulos, estandariza la estructura de los módulos de programación Avance en Hard: equipos de mayor capacidad. Pero la programación estructurada puede derrumbarse cuando hay más de 100.000 líneas de código (Stein) Inapropiado para su uso en lenguajes de programación basados en objetos y orientados a objetos Inapropiado para sistemas muy complejos
    • Metodologías de Diseño Estructurado o Diseño Compuesto Herramientas utilizadas para describir lógicamente un sistema: Diagramas de Flujo: modelan las transformaciones de los datos en su flujo por el sistema. Núcleo del enfoque estructurado. Los procesos complejos se van dividiendo recursivamente en subdiagramas, que quedan cada vez más sencillos y fáciles de implementar. Cuando los procesos resultantes son lo suficientemente simples, se detiene la descomposición. Especificación de Procesos : descripción de cada proceso de más bajo nivel. Se especifican con tablas de decisión, seudocódigos, etc. Diccionarios de Datos : Contienen detalles que escapan a los diagramas de flujos. Definen los flujos y almacenamientos de datos y el significado de los nombres. Diagramas de Transición de Estados: Describen los procesos controladores o el tiempo de ejecución de funciones y de acceso de datos activados por eventos Diagramas de Entidad/Relación : enfoca relaciones entre bases de datos
    • 2º) Metodologías de Diseño Dirigido a los Datos Por Jackson y Orr. Popular en Europa La estructura de un sistema de software se deduce de la correspondencia entre entradas y salidas del sistema Exitoso para sistemas de gestión de información Sistemas que impliquen relaciones directas entre entradas y salidas del sistema No atiende eventos internos No distingue entre Análisis y Diseño: Une a ambas en ESPECIFICACION Divide el Desarrollo en dos etapas: ESPECIFICACION (qué) e IMPLEMENTACION (cómo)
    • Metodologías de Diseño Dirigido a los Datos Orientada a los datos y no a los procesos Comienza con el diseño de las estructuras de datos La estructura del programa deriva de las estructuras de datos Asume que el problema ha sido completamente especificado antes del diseño Enfoca en las salidas (outputs) del sistema Filosofía: Los outputs del sistema en forma absoluta y completa determinan la estructura de datos, y la estructura de datos, a su vez, determina la estructura del programa Comienza con una descripción jerárquica de las salidas del sistema La estructura de los inputs y de los programas del sistema derivan necesariamente de la estructura de los outputs
      • Sistema de Software => Conjunto de Objetos que cooperan , y se tratan como instancias de una clase que está dentro de una jerarquía de clases.
      • Surgidos a partir de los ‘90.
      • Reflejado en lenguajes de alto nivel: Smalltalk, Object Pascal, C++, Ada, Java, etc.
      3º) Diseño Orientado a Objetos
    • Diseño Estructurado Vs. Diseño Orientado a Objetos Descomposición Algorítmica: Diseño Estructurado Descendente Descomposición Orientada a Objetos: Cada módulo del sistema es un paso importante de algún proceso global alternativa para el mismo problema. Es una descomposición basada en OBJETOS y NO en ALGORITMOS Diagramas de Flujo. Organiza el sistema en base a procedimientos Se organiza el sistema como un conjunto de objetos reales o conceptuales que existen en la visión que el usuario tiene del mundo Descompone el problema en pasos Cada objeto contiene su propio comportamiento único y modela a un objeto del mundo real
    • Diseño Estructurado Vs. Diseño Orientado a Objetos Descomposición Algorítmica: Diseño Estructurado Descendente Descomposición Orientada a Objetos: Enfatiza el Orden de los Eventos Los objetos hacen cosas, y a los objetos se les pide que las hagan enviándoles mensajes Descomposición funcional. El sistema proporciona funciones al usuario final Resalta los agentes que causan acciones o son objetos de acciones Visión Activa de la Realidad Visión Pasiva Cambios en requerimientos: desastroso porque hay que replantear todo Cambios en los requerimientos: cambios en las funciones y no en los objetos. Fácil: se agregan o quitan funciones a cada objeto. Se deja sin cambios la estructura del objeto.
    • Diseño Estructurado Vs. Diseño Orientado a Objetos Descomposición Algorítmica: Diseño Estructurado Descendente Descomposición Orientada a Objetos: Útil en los casos en que las funciones sean más importantes y complejas que los datos Existe una analogía directa entre objetos de la vida real y los objetos del problema. Son sistemas más fáciles de comprender para el usuario. Diseño más intuitivo. Simplifica el seguimiento entre requerimientos y codificación Tiene los límites claramente definidos del sistema. Su estructura deriva de los límites del sistema. Es difícil extenderlos Es Fácil ampliar un sistema. Son más resistentes al cambio. Evolucionan mejor. Reduce el riesgo de construir sistemas complejos La descomposición de un proceso en subprocesos es arbitraria y cambia de persona a persona La descomposición se basa en objetos del dominio del problema. Desarrolladores de diferentes programas en el mismo dominio tienden a descubrir los mismos objetos
    • Diseño Estructurado Vs. Diseño Orientado a Objetos Descomposición Algorítmica: Diseño Estructurado Descendente Descomposición Orientada a Objetos: Los programadores piensan en términos de funciones. Son más fáciles de aprender Facilita la reusabilidad de componentes de un proyecto a otro. Es difícil integrar código de programas basado en funciones y bases de datos organizadas como datos Integra mejor bases de datos con codificación. Primera metodología formal bien pensada, disciplinada y organizada destinada al desarrollo de software Produce sistemas más pequeños: reuso de mecanismos comunes
      • Conclusiones:
      • Ambas visiones son contrapuestas.
      • No puede diseñarse un sistema complejo con las dos visiones a la vez.
      • Hay que descomponer un sistema por algoritmos u objetos y utilizar la estructura resultante como marco de referencia.
      Diseño Estructurado Vs. Diseño Orientado a Objetos
      • «Ingeniería del Software», de Ian Sommerville, 8.5
      • Métodos Estructurados
      • Forma sistemática de elaborar modelos de un sistema existente o de un sistema que tiene que ser construido.
      • Desarrollados por primera vez en la década de los ‘70 para soportar el Análisis y el Diseño del Software. (Constantine y Yourdon, 1979; Gane y Sarson, 1979; Jackson, 1983)
      Modelos de Desarrollo Estructurado
      • Los métodos estructurados proporcionan un marco para el modelado detallado de sistemas.
      • Pueden suponer reducciones significativas de costos porque utilizan notaciones estándar producen una documentación de diseño estándar.
      Métodos Estructurados
      • No dan soporte efectivo para comprender o modelar requerimientos del sistema no funcionales.
      • Casi no incluyen guías que ayuden a los usuarios a decidir si un método es adecuado para un problema concreto.
      • Tampoco incluyen consejos sobre cómo adaptar su uso en un entorno particular.
      Métodos Estructurados Inconvenientes
      • Generan demasiada documentación.
      • La esencia de los Requerimientos del Sistema puede quedar oculta por el volumen de detalle que se incluye.
      • Los modelos producidos son muy detallados.
      • Pueden ser difíciles de entender para los usuarios, que no pueden comprobar el realismo de estos modelos, por ser tan específicos.
      Métodos Estructurados Inconvenientes
      • Las herramientas CASE de Análisis y Diseño soportan la creación, edición y análisis de las notaciones gráficas utilizadas en los métodos estructurados.
      • La Figura siguiente nos muestra los componentes de una herramienta CASE de esa naturaleza.
      Métodos Estructurados Herramientas Case
    • Componentes de una herramienta CASE para el soporte de métodos estructurados
      • Editores de diagramas: crean modelos de objetos, modelos de datos, modelos de comportamiento, etcétera. No son sólo herramientas de dibujo; pues, identifican los tipos de entidades en el diagrama. Captan la información sobre estas entidades y la guardan en el repositorio central.
      • Herramientas de análisis y comprobación de diseños: procesan el Diseño e informan sobre errores y anomalías. Permite detectar los errores del usuario en etapas tempranas del proceso de desarrollo.
      • Lenguajes de consulta del repositorio: permite encontrar diseños e información asociada a los diseños en el almacén.
      Componentes de una herramienta CASE para el soporte de métodos estructurados
      • Un diccionario de datos: mantiene información sobre las entidades utilizadas en el diseño de un sistema.
      • Herramientas de generación y definición de informes: obtienen información del almacén central y generan automáticamente la documentación del sistema.
      • Herramientas de definición de formularios: permiten especificar los formatos de pantallas y de documentos.
      Componentes de una herramienta CASE para el soporte de métodos estructurados
      • Facilidades para importar/exportar: Permiten el intercambio de información desde el Repositorio Central con otras herramientas de desarrollo.
      • Generadores de Código: generan código o esqueletos de código automáticamente, a partir del Diseño capturado en el Almacén Central.
      Componentes de una herramienta CASE para el soporte de métodos estructurados
      • Permiten al usuario generar programas a partir de información proporcionada en el modelo del sistema.
      • Soportan diferentes lenguajes, para que el usuario pueda generar programas, a partir del mismo modelo de Diseño.
      • Como los modelos excluyen detalles de bajo nivel, el generador de código no puede normalmente generar el sistema completo.
      • Por eso es necesaria alguna codificación manual para añadir detalles al código generado.
      Herramientas CASE
      • «Ingeniería del Software», de Ian Sommerville, 4.5,1
      • Las herramientas Case se pueden clasificar desde 3 puntos de vista distintos:
      • 1) Una perspectiva funcional: de acuerdo con su función específica.
      • 2) Una perspectiva de proceso: de acuerdo con las actividades del proceso que ayudan.
      • 3) Una perspectiva de integración: de acuerdo con cómo están organizadas en unidades integradas que proporcionan ayuda a una o más actividades del proceso.
      Clasificación de Herramientas Case
      • La Figura siguiente muestra una clasificación de las herramientas CASE acorde con su función.
      • Enumera diferentes tipos y da ejemplos específicos de cada una.
      • No es una lista completa de herramientas CASE.
      • Las herramientas especializadas, como las de ayuda a la reutilización, no se incluyen.
      Clasificación de herramientas CASE según su función
    • Clasificación de herramientas CASE según su función
      • La Figura siguiente muestra las fases del proceso que reciben ayuda por varios tipos de herramientas CASE.
      Clasificación de herramientas CASE según la perspectiva del proceso
    • Clasificación de herramientas CASE según la perspectiva del proceso
      • Las Herramientas para:
      • La planificación y estimación,
      • Edición de Texto,
      • Preparación de Documentos
      • Gestión de la Configuración
      • Se pueden utilizar durante todo el Proceso del Software .
      Clasificación de herramientas CASE según la perspectiva del proceso
      • En función de la amplia ayuda que ofrece la tecnología CASE para el proceso del software , los sistemas CASE se pueden clasificar en tres categorías:
      • 1. Herramientas : ayudan a las tareas individuales del proceso (compilación de un programa y la comparación de los resultados de las pruebas). Las herramientas pueden ser de propósito general, independientes (procesador de texto) o agrupadas en bancos de trabajo.
      • 2. Bancos de trabajo : ayudan a las fases o actividades del proceso (especificación/análisis, diseño, etc.). Son un conjunto de herramientas con algún grado de integración.
      Clasificación de herramientas CASE según la perspectiva de Integración
      • 3. Entornos : ayudan a todos los procesos del software, o una parte sustancial de éstos. Normalmente incluyen varios bancos de trabajo integrados.
      • La Figura siguiente ilustra esta clasificación y muestra algunos ejemplos de estas clases de ayuda CASE .
      Clasificación de herramientas CASE según la perspectiva de Integración
    • Clasificación de herramientas CASE según la perspectiva de Integración
      • Herramientas de propósito general : se usan a discreción del ingeniero de software, quien decide cuándo aplicarlas para ayudar al proceso.
      • Bancos de Trabajo: ayudan a algún método que incluye un modelo del proceso y un conjunto de reglas/pautas que se aplican al software en desarrollo.
      • Entornos: se clasifican en integrados y centrados en el proceso.
      Clasificación de herramientas CASE según la perspectiva de Integración
      • Entornos Integrados: brindan ayuda a los datos, al control y a la integración de la presentación.
      • Entornos Centrados en Procesos: son más generales. Incluyen el conocimiento del proceso del software y un motor de procesos para aconsejar a los ingenieros qué herramientas o bancos de trabajo aplicar y cuándo deben utilizarse.
      Clasificación de herramientas CASE según la perspectiva de Integración
      • Advertencias:
      • En la práctica, los límites entre estas diferentes clases son borrosos. Las herramientas se pueden vender como productos individuales, y ayudar a diferentes actividades.
      • Ejemplo: Muchos procesadores de texto incluyen un editor de diagramas integrado. Los bancos de trabajo CASE para el diseño normalmente ayudan a la programación y a las pruebas (se relacionan más con el entorno que con los bancos de trabajo especializados).
      Clasificación de herramientas CASE
      • Conclusiones:
      • No siempre es fácil ubicar un producto utilizando una clasificación.
      • Sin embargo, la clasificación brinda un primer paso útil para ayudara entender la amplitud de los servicios que los sistemas CASE pueden proporcionar al Proceso de Desarrollo de Software.
      Clasificación de herramientas CASE