SlideShare una empresa de Scribd logo
1 de 49
Descargar para leer sin conexión
Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
Contenidos de la Unidad 1 Introducción al Diseño  ,[object Object],  b.  Modelos de Desarrollo de software   ,[object Object],Sommerville. Sección 8.5 y 4.5.1 Pressman. Sección 2.10 ,[object Object],Sommervillle. Sección 4.1.1. Pressman. Sección 2.4. ,[object Object],Sommervillle. Sección 4.1.2. Pressman. Sección 2.7  ,[object Object],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
[object Object],[object Object],[object Object],[object Object],Unidad I: Significado dentro del Ciclo de Vida de Desarrollo de Sistemas
[object Object],[object Object],[object Object],[object Object],[object Object],A) Software Simple Vs. Software Complejo
[object Object],[object Object],[object Object],[object Object],[object Object],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
[object Object],[object Object],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
[object Object],[object Object],[object Object],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
[object Object],[object Object],[object Object],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
[object Object],[object Object],[object Object],[object Object],Diseño Estructurado Vs. Diseño Orientado a Objetos
[object Object],[object Object],[object Object],[object Object],Modelos de Desarrollo Estructurado
[object Object],[object Object],Métodos Estructurados
[object Object],[object Object],[object Object],Métodos Estructurados Inconvenientes
[object Object],[object Object],[object Object],[object Object],Métodos Estructurados Inconvenientes
[object Object],[object Object],Métodos Estructurados Herramientas Case
Componentes de una herramienta CASE para el soporte de métodos estructurados
[object Object],[object Object],[object Object],Componentes de una herramienta CASE para el soporte de métodos estructurados
[object Object],[object Object],[object Object],Componentes de una herramienta CASE para el soporte de métodos estructurados
[object Object],[object Object],Componentes de una herramienta CASE para el soporte de métodos estructurados
[object Object],[object Object],[object Object],[object Object],Herramientas CASE
[object Object],[object Object],[object Object],[object Object],[object Object],Clasificación de Herramientas Case
[object Object],[object Object],[object Object],[object Object],Clasificación de herramientas CASE según su función
Clasificación de herramientas CASE según su función
[object Object],Clasificación de herramientas CASE según la perspectiva del proceso
Clasificación de herramientas CASE según la perspectiva del proceso
[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Clasificación de herramientas CASE según la perspectiva del proceso
[object Object],[object Object],[object Object],Clasificación  de herramientas  CASE  según la perspectiva de  Integración
[object Object],[object Object],Clasificación  de herramientas  CASE  según la perspectiva de  Integración
Clasificación  de herramientas  CASE  según la perspectiva de  Integración
[object Object],[object Object],[object Object],Clasificación  de herramientas  CASE  según la perspectiva de  Integración
[object Object],[object Object],Clasificación  de herramientas  CASE  según la perspectiva de  Integración
[object Object],[object Object],[object Object],Clasificación  de herramientas  CASE
[object Object],[object Object],[object Object],Clasificación  de herramientas  CASE

Más contenido relacionado

La actualidad más candente

Diseno Software
Diseno SoftwareDiseno Software
Diseno Softwarealfmuny
 
Conceptos de diseño de software
Conceptos de diseño de softwareConceptos de diseño de software
Conceptos de diseño de softwareJose Diaz Silva
 
4. Diseño e Implementación de Software
4. Diseño e Implementación de Software4. Diseño e Implementación de Software
4. Diseño e Implementación de SoftwareMario A Moreno Rocha
 
Arquitecturas de software - Parte 1
Arquitecturas de software - Parte 1Arquitecturas de software - Parte 1
Arquitecturas de software - Parte 1Marta Silvia Tabares
 
Arquitectura del software
Arquitectura del softwareArquitectura del software
Arquitectura del softwareJohns Chacon
 
Desarrollo de software diapositiva
Desarrollo  de software diapositivaDesarrollo  de software diapositiva
Desarrollo de software diapositivaNorma Rodriguez
 
Diseno de la arquitectura
Diseno de la arquitecturaDiseno de la arquitectura
Diseno de la arquitecturaFatima Cham
 
Metodología para el desarrollo del sistemas de información y comunicación seg...
Metodología para el desarrollo del sistemas de información y comunicación seg...Metodología para el desarrollo del sistemas de información y comunicación seg...
Metodología para el desarrollo del sistemas de información y comunicación seg...travesuras79
 
Metodologías de desarrollo de software ucp
Metodologías de desarrollo de software   ucpMetodologías de desarrollo de software   ucp
Metodologías de desarrollo de software ucpAlonso Toro Lazo
 
Fundamentos del Diseño de Software
Fundamentos del Diseño de SoftwareFundamentos del Diseño de Software
Fundamentos del Diseño de SoftwareNelson Guanipa
 
Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de softwareDiaxz Salgado
 
Fundamentos basicos del diseño de software
Fundamentos basicos del diseño de softwareFundamentos basicos del diseño de software
Fundamentos basicos del diseño de softwareJesús Molleda
 
Clasificaion de las metodologias de desarrollo de software
Clasificaion de las metodologias de desarrollo de softwareClasificaion de las metodologias de desarrollo de software
Clasificaion de las metodologias de desarrollo de softwareTrabajos Grupal Ing de Software
 
Ingeniería de software II - Parte 4
Ingeniería de software II - Parte 4Ingeniería de software II - Parte 4
Ingeniería de software II - Parte 4Marta Silvia Tabares
 
Fundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas IIFundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas IIJimmyWilfredMassVerd
 

La actualidad más candente (19)

Diseno Software
Diseno SoftwareDiseno Software
Diseno Software
 
Principios diseño del software
Principios diseño del software Principios diseño del software
Principios diseño del software
 
Is.1p.5 arquitectura de software
Is.1p.5 arquitectura de softwareIs.1p.5 arquitectura de software
Is.1p.5 arquitectura de software
 
Conceptos de diseño de software
Conceptos de diseño de softwareConceptos de diseño de software
Conceptos de diseño de software
 
4. Diseño e Implementación de Software
4. Diseño e Implementación de Software4. Diseño e Implementación de Software
4. Diseño e Implementación de Software
 
Arquitecturas de software - Parte 1
Arquitecturas de software - Parte 1Arquitecturas de software - Parte 1
Arquitecturas de software - Parte 1
 
Arquitectura del software
Arquitectura del softwareArquitectura del software
Arquitectura del software
 
Desarrollo de software diapositiva
Desarrollo  de software diapositivaDesarrollo  de software diapositiva
Desarrollo de software diapositiva
 
Diseno de la arquitectura
Diseno de la arquitecturaDiseno de la arquitectura
Diseno de la arquitectura
 
Metodología para el desarrollo del sistemas de información y comunicación seg...
Metodología para el desarrollo del sistemas de información y comunicación seg...Metodología para el desarrollo del sistemas de información y comunicación seg...
Metodología para el desarrollo del sistemas de información y comunicación seg...
 
Unidad 4
Unidad 4Unidad 4
Unidad 4
 
Metodologías de desarrollo de software ucp
Metodologías de desarrollo de software   ucpMetodologías de desarrollo de software   ucp
Metodologías de desarrollo de software ucp
 
Fundamentos del Diseño de Software
Fundamentos del Diseño de SoftwareFundamentos del Diseño de Software
Fundamentos del Diseño de Software
 
Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
Fundamentos basicos del diseño de software
Fundamentos basicos del diseño de softwareFundamentos basicos del diseño de software
Fundamentos basicos del diseño de software
 
Clasificaion de las metodologias de desarrollo de software
Clasificaion de las metodologias de desarrollo de softwareClasificaion de las metodologias de desarrollo de software
Clasificaion de las metodologias de desarrollo de software
 
Ingeniería de software II - Parte 4
Ingeniería de software II - Parte 4Ingeniería de software II - Parte 4
Ingeniería de software II - Parte 4
 
Fundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas IIFundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas II
 
Diseño de Software
Diseño de SoftwareDiseño de Software
Diseño de Software
 

Destacado

Tratamientos de los trastornos funcionales del sistema masticatorio pdf
Tratamientos de los trastornos funcionales del sistema masticatorio pdfTratamientos de los trastornos funcionales del sistema masticatorio pdf
Tratamientos de los trastornos funcionales del sistema masticatorio pdfAlonso Garache Valle
 
Pruebas funcionales de ruptura del manguito rotador
Pruebas funcionales de ruptura del manguito rotadorPruebas funcionales de ruptura del manguito rotador
Pruebas funcionales de ruptura del manguito rotadorChivo Mtz Padilla
 
Nomenclatura de grupos funcionales
Nomenclatura de grupos funcionalesNomenclatura de grupos funcionales
Nomenclatura de grupos funcionalesRamón Olivares
 
Los tipos textos funcionales
Los tipos textos funcionalesLos tipos textos funcionales
Los tipos textos funcionalesmarianoprdmd
 
Terminología médica clinicas
Terminología médica clinicasTerminología médica clinicas
Terminología médica clinicasHowardBv
 
Valoracion por patrones funcionales en ppt
Valoracion por patrones funcionales  en pptValoracion por patrones funcionales  en ppt
Valoracion por patrones funcionales en pptOrlando Romerozea
 
Terminologia medica
Terminologia medicaTerminologia medica
Terminologia medicaAna Garcia
 

Destacado (9)

Tratamientos de los trastornos funcionales del sistema masticatorio pdf
Tratamientos de los trastornos funcionales del sistema masticatorio pdfTratamientos de los trastornos funcionales del sistema masticatorio pdf
Tratamientos de los trastornos funcionales del sistema masticatorio pdf
 
Pruebas funcionales de ruptura del manguito rotador
Pruebas funcionales de ruptura del manguito rotadorPruebas funcionales de ruptura del manguito rotador
Pruebas funcionales de ruptura del manguito rotador
 
Nomenclatura de grupos funcionales
Nomenclatura de grupos funcionalesNomenclatura de grupos funcionales
Nomenclatura de grupos funcionales
 
Los tipos textos funcionales
Los tipos textos funcionalesLos tipos textos funcionales
Los tipos textos funcionales
 
BiomecáNica De La Rodilla
BiomecáNica De La RodillaBiomecáNica De La Rodilla
BiomecáNica De La Rodilla
 
Biomecanica De La Rodilla
Biomecanica De La RodillaBiomecanica De La Rodilla
Biomecanica De La Rodilla
 
Terminología médica clinicas
Terminología médica clinicasTerminología médica clinicas
Terminología médica clinicas
 
Valoracion por patrones funcionales en ppt
Valoracion por patrones funcionales  en pptValoracion por patrones funcionales  en ppt
Valoracion por patrones funcionales en ppt
 
Terminologia medica
Terminologia medicaTerminologia medica
Terminologia medica
 

Similar a Significado dentro del ciclo de vida de desarrollo de sistemas

Apuntes ing-sof-unidad-4-1-2015
Apuntes ing-sof-unidad-4-1-2015Apuntes ing-sof-unidad-4-1-2015
Apuntes ing-sof-unidad-4-1-2015Lucero Mtz
 
Tipos de modelos de procesos
Tipos de modelos de procesosTipos de modelos de procesos
Tipos de modelos de procesosEIYSC
 
Trabajo de Christian Oblitas
Trabajo de Christian OblitasTrabajo de Christian Oblitas
Trabajo de Christian OblitasChristian1705
 
Diseño de sistemas
Diseño de sistemasDiseño de sistemas
Diseño de sistemasMirna Lozano
 
Metodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemasMetodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemasEliset Gonzales Uceda
 
Fundamentos del software
Fundamentos del softwareFundamentos del software
Fundamentos del softwaremrquaife
 
Fundamentos de desarrollo de sistemas
Fundamentos de desarrollo de sistemasFundamentos de desarrollo de sistemas
Fundamentos de desarrollo de sistemasflaco_mendez
 
Proyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteProyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteCAMILO
 
94368577 unidad-iii-y-iv
94368577 unidad-iii-y-iv94368577 unidad-iii-y-iv
94368577 unidad-iii-y-ivIvan Moreno
 
Diapositiva de analista en sistemas
Diapositiva de analista en sistemasDiapositiva de analista en sistemas
Diapositiva de analista en sistemasDiego Sanchez
 
Ciclo De Vida De Los Sistemas
Ciclo De Vida De Los SistemasCiclo De Vida De Los Sistemas
Ciclo De Vida De Los SistemasUNM
 
Ciclo De Vida De Los Sistemas
Ciclo De Vida De Los SistemasCiclo De Vida De Los Sistemas
Ciclo De Vida De Los SistemasUNM
 
Articulo de análisis y diseño de sistemas
Articulo de análisis y diseño de sistemasArticulo de análisis y diseño de sistemas
Articulo de análisis y diseño de sistemasMario J Arrieta
 
Diseño de sistemas
Diseño de sistemasDiseño de sistemas
Diseño de sistemasAlan9126
 
Analisis de Sistemas_Sesion1
Analisis de Sistemas_Sesion1Analisis de Sistemas_Sesion1
Analisis de Sistemas_Sesion1Teresa Cossio
 

Similar a Significado dentro del ciclo de vida de desarrollo de sistemas (20)

Apuntes ing-sof-unidad-4-1-2015
Apuntes ing-sof-unidad-4-1-2015Apuntes ing-sof-unidad-4-1-2015
Apuntes ing-sof-unidad-4-1-2015
 
Diseño
DiseñoDiseño
Diseño
 
Tipos de modelos de procesos
Tipos de modelos de procesosTipos de modelos de procesos
Tipos de modelos de procesos
 
Ciclo de vida cascada
Ciclo de vida cascadaCiclo de vida cascada
Ciclo de vida cascada
 
Trabajo de Christian Oblitas
Trabajo de Christian OblitasTrabajo de Christian Oblitas
Trabajo de Christian Oblitas
 
Diseño de sistemas
Diseño de sistemasDiseño de sistemas
Diseño de sistemas
 
Metodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemasMetodologías para el desarrollo de sistemas
Metodologías para el desarrollo de sistemas
 
Fundamentos del software
Fundamentos del softwareFundamentos del software
Fundamentos del software
 
Fundamentos de desarrollo de sistemas
Fundamentos de desarrollo de sistemasFundamentos de desarrollo de sistemas
Fundamentos de desarrollo de sistemas
 
Proyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteProyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de Coste
 
Tema 1 introduccion al diseno software
Tema 1 introduccion al diseno softwareTema 1 introduccion al diseno software
Tema 1 introduccion al diseno software
 
94368577 unidad-iii-y-iv
94368577 unidad-iii-y-iv94368577 unidad-iii-y-iv
94368577 unidad-iii-y-iv
 
Diapositiva de analista en sistemas
Diapositiva de analista en sistemasDiapositiva de analista en sistemas
Diapositiva de analista en sistemas
 
Ciclo De Vida De Los Sistemas
Ciclo De Vida De Los SistemasCiclo De Vida De Los Sistemas
Ciclo De Vida De Los Sistemas
 
Ciclo De Vida De Los Sistemas
Ciclo De Vida De Los SistemasCiclo De Vida De Los Sistemas
Ciclo De Vida De Los Sistemas
 
Adrian adrianza
Adrian adrianzaAdrian adrianza
Adrian adrianza
 
Ciclo de vida
Ciclo de vidaCiclo de vida
Ciclo de vida
 
Articulo de análisis y diseño de sistemas
Articulo de análisis y diseño de sistemasArticulo de análisis y diseño de sistemas
Articulo de análisis y diseño de sistemas
 
Diseño de sistemas
Diseño de sistemasDiseño de sistemas
Diseño de sistemas
 
Analisis de Sistemas_Sesion1
Analisis de Sistemas_Sesion1Analisis de Sistemas_Sesion1
Analisis de Sistemas_Sesion1
 

Más de Juan Pablo Bustos Thames

El Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
El Proceso de Diseño de Interfaz del Usuario por Ian SommervilleEl Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
El Proceso de Diseño de Interfaz del Usuario por Ian SommervilleJuan Pablo Bustos Thames
 
El Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger PressmanEl Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger PressmanJuan Pablo Bustos Thames
 
Descomposición modular y estilos de control
Descomposición modular y estilos de controlDescomposición modular y estilos de control
Descomposición modular y estilos de controlJuan Pablo Bustos Thames
 
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...Juan Pablo Bustos Thames
 
Soluciones con objetos y patrones. visibilidad
Soluciones con objetos y patrones. visibilidadSoluciones con objetos y patrones. visibilidad
Soluciones con objetos y patrones. visibilidadJuan Pablo Bustos Thames
 
Patrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. graspPatrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. graspJuan Pablo Bustos Thames
 
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...Juan Pablo Bustos Thames
 
Del análisis al diseño. diagramas de secuencia y contratos
Del análisis al diseño. diagramas de secuencia y contratosDel análisis al diseño. diagramas de secuencia y contratos
Del análisis al diseño. diagramas de secuencia y contratosJuan Pablo Bustos Thames
 
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoPrimeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoJuan Pablo Bustos Thames
 

Más de Juan Pablo Bustos Thames (20)

Pruebas del Software
Pruebas del SoftwarePruebas del Software
Pruebas del Software
 
Verificación y Validación del Diseño
Verificación y Validación del DiseñoVerificación y Validación del Diseño
Verificación y Validación del Diseño
 
Diseño a Nivel de Componentes
Diseño a Nivel de ComponentesDiseño a Nivel de Componentes
Diseño a Nivel de Componentes
 
El Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
El Proceso de Diseño de Interfaz del Usuario por Ian SommervilleEl Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
El Proceso de Diseño de Interfaz del Usuario por Ian Sommerville
 
El Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger PressmanEl Proceso de Diseño de interfaces de usuario. Roger Pressman
El Proceso de Diseño de interfaces de usuario. Roger Pressman
 
Reglas de Oro
Reglas de OroReglas de Oro
Reglas de Oro
 
Diseño de interfaces
Diseño de interfacesDiseño de interfaces
Diseño de interfaces
 
Modelos de dominio específicos
Modelos de dominio específicosModelos de dominio específicos
Modelos de dominio específicos
 
Arquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidosArquitectura de sistemas distribuidos
Arquitectura de sistemas distribuidos
 
Descomposición modular y estilos de control
Descomposición modular y estilos de controlDescomposición modular y estilos de control
Descomposición modular y estilos de control
 
Diseño arquitectónico
Diseño arquitectónicoDiseño arquitectónico
Diseño arquitectónico
 
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
Visibilidad. Paquetes, Estratos y Particiones. Diagramas de Estado y de Activ...
 
Diagramas de clases
Diagramas de clasesDiagramas de clases
Diagramas de clases
 
Soluciones con objetos y patrones. visibilidad
Soluciones con objetos y patrones. visibilidadSoluciones con objetos y patrones. visibilidad
Soluciones con objetos y patrones. visibilidad
 
Patrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. graspPatrones para asignar responsabilidades. grasp
Patrones para asignar responsabilidades. grasp
 
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
Del análisis al diseño. conclusión de la fase del análisis. diagramas de cola...
 
Del análisis al diseño. diagramas de secuencia y contratos
Del análisis al diseño. diagramas de secuencia y contratosDel análisis al diseño. diagramas de secuencia y contratos
Del análisis al diseño. diagramas de secuencia y contratos
 
Modelos de dominio
Modelos de dominioModelos de dominio
Modelos de dominio
 
Modelos de dominio
Modelos de dominioModelos de dominio
Modelos de dominio
 
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoPrimeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
 

Significado dentro del ciclo de vida de desarrollo de sistemas

  • 1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
  • 2.
  • 3.
  • 4.
  • 5.
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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
  • 10. 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
  • 11.
  • 12. 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
  • 13. 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
  • 14. 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
  • 15.
  • 16. 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
  • 17. 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
  • 18. 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
  • 19. 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)
  • 20. 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
  • 21.
  • 22. 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
  • 23. 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.
  • 24. 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
  • 25. 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
  • 26.
  • 27.
  • 28.
  • 29.
  • 30.
  • 31.
  • 32. Componentes de una herramienta CASE para el soporte de métodos estructurados
  • 33.
  • 34.
  • 35.
  • 36.
  • 37.
  • 38.
  • 39. Clasificación de herramientas CASE según su función
  • 40.
  • 41. Clasificación de herramientas CASE según la perspectiva del proceso
  • 42.
  • 43.
  • 44.
  • 45. Clasificación de herramientas CASE según la perspectiva de Integración
  • 46.
  • 47.
  • 48.
  • 49.