• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Introducción  a la Ingeniería de Software:Qué es un Buen Sistema?
 

Introducción a la Ingeniería de Software:Qué es un Buen Sistema?

on

  • 25,490 views

Introducción a la Ingeniería de Software:Qué es un Buen Sistema?

Introducción a la Ingeniería de Software:Qué es un Buen Sistema?

Statistics

Views

Total Views
25,490
Views on SlideShare
25,066
Embed Views
424

Actions

Likes
1
Downloads
598
Comments
0

12 Embeds 424

http://ingdelsoftware.blogspot.com 244
http://www.slideshare.net 89
http://pcsig2007.wikispaces.com 30
http://ingdelsoftware.blogspot.mx 24
http://www.edudigital.net 15
http://mscingsw.blogspot.com 11
http://www.ingdelsoftware.blogspot.com 5
http://mscingsw.blogspot.mx 2
http://www.blogger.com 1
http://ingdelsoftware.blogspot.co.uk 1
http://ingdelsoftware.blogspot.com.ar 1
http://ingdelsoftware.blogspot.com.es 1
More...

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

    Introducción  a la Ingeniería de Software:Qué es un Buen Sistema? Introducción a la Ingeniería de Software:Qué es un Buen Sistema? Presentation Transcript

    • Introducción a la Ingeniería de Software: Qué es un Buen Sistema? Adaptado de http :// comunidad.uach.mx / fmarisc / analisis / Analisis.ppt
    • Ingeniería de Software
      • ¿ Qué es un BUEN SISTEMA?
        • Un buen sistema (o uno de alta calidad) es aquél que cumple con las necesidades del cliente. El sistema debe ser:
          • UTIL y UTILIZABLE : Un buen software hace más fácil o mejor la vida a las personas.
          • CONFIABLE : Un buen software tiene pocos errores.
          • FLEXIBLE : Las necesidades cambian con el tiempo, aún cuando el software se está desarrollando, entonces es importante poder hacer cambios posteriores al software. Debe podérsele dar mantenimiento después de liberado.
    • Ingeniería de Software
      • ¿ Qué es un BUEN SISTEMA?
          • FLEXIBLE : Las necesidades cambian con el tiempo, aún cuando el software se está desarrollando, entonces es importante poder hacer cambios posteriores al software. Debe podérsele dar mantenimiento después de liberado.
          • ACCESIBLE : tanto para comprar como para mantener. Debe ser razonablemente fácil y rápido poderlo desarrollar o darle mantenimiento.
          • DISPONIBLE : De otra forma no importa que tan bueno es. Debe ser capaz de ejecutarse el el hardware disponible y con el sistema operativo disponible, etc. Debe existir y entregarse el software prometido.
    • Ingeniería de Software
      • ¿Tenemos buenos sistemas?
        • Existen avances satisfactorios en sistemas de software modernos: contabilidad, bancos, búsqueda de información, etc. Lo que indica que estamos haciendo las cosas correctamente.
    • Ingeniería de Software
      • Problemas:
        • Hay sistemas que no cumplen con las necesidades de los usuarios y/o tienen fallas técnicas.
        • Generalmente, los sistemas no están actualizados ni cuando se están diseñando.
    • Ingeniería de Software
      • Problemas:
        • Aún existe el “error de la computadora” como excusa a un mal servicio a los clientes.
        • La mayoría de los usuarios de PCs esperan que sus aplicaciones y aún el sistema operativo se “caiga” o “congele” de vez en cuando.
    • Ingeniería de Software
      • Problemas:
        • EL SOFTWARE NO SIEMPRE ES UTILIZABLE, ÚTIL, CONFIABLE O DISPONIBLE.
        • La falta de FLEXIBILIDAD también resulta evidente, como lo muestran el problema del milenio y la adecuación de todos los sistemas viejos (legacy) a procesos de negocios cambiantes.
    • Ingeniería de Software
      • Problemas:
        • La COSTEABILIDAD se relaciona mucho con la confiabilidad y la flexibilidad debido a que el costo de corregir y mantener es el más alto costo asociado con el software
    • Ingeniería de Software
      • Problemas aún más drásticos.
        • A veces las fallas en algunos de los atributos deseables de los sistemas han provocado catástrofes como las siguientes:
          • Ariane 5 : Fallas de software hacen explotar la nave (1996)
          • Taurus : Mercado accionario londinense no pudieron terminar proyecto de software y tuvieron grandes pérdidas (1993)
    • Ingeniería de Software
      • Problemas aún más drásticos.
          • Manejo de maletas de Denver : Fallas del sistema y el alto costo de corregirlo, no permitía al aeropuerto abrir a tiempo.
          • Sistema de Ambulancias de Londres : Fallas de diseño y de ejecución provocaron la muerte de gente por falta de ambulancias (1992)
          • Therac-25 : Sobredosis radioactivas por fallas en el software de la máquina a varias personas (1987)
    • Ingeniería de Software
      • Problemas aún más drásticos.
        • Según W. Wayt Gibbs en Software’s chronic crisis. Scientific American (International Ed.) pp 72-81, Sep. 1994. dice:
          • En promedio, los proyectos grandes toman 50% más de tiempo de lo planeado;
          • 75% de los proyectos grandes tienen fallas operacionales;
          • 25% de los proyectos grandes son cancelados
    • Ingeniería de Software
      • Promesas, promesas
        • Cada nueva tecnología promete reducir los tiempos de desarrollo e incrementar los promedios de éxito de los proyectos.
        • Todos lo dudamos.
    • Ingeniería de Software
      • Promesas, promesas
        • Según Frederick P. Brooks (The mythical man-month, Addison-Wesley 1975/1995), mientras más grande sea el proyecto, mayor será la proporción del costo y tiempo del proyecto gastado en la comunicación entre la gente del proyecto, porque cada persona tiene más gente con quién comunicarse. Cuando un proyecto empieza a quedarse atrás en el tiempo, el poner más gente por lo general falla.
    • Ingeniería de Software
      • Promesas, promesas
        • El Departamento de Defensa de EU, intentó resolver la crisis del software y comisionó el diseño del lenguaje de programación ADA, el cual se estandarizó en 1983, el cual soportaba lo mejor de los conceptos de análisis, diseño y programación estructurados, la modularidad y la encapsulación fueron conceptos clave en el diseño del lenguaje, pero aún esta enorme inversión ha fracasado.
    • Ingeniería de Software
      • ¿Cómo son los sistemas considerados buenos?
        • El problema fundamental para comprenderlos es:
          • Hay un límite de cuánto puede entender un humano en un momento dado
    • Ingeniería de Software
      • ¿Cómo son los sistemas considerados buenos?
        • Los sistemas pequeños, son realizados mediante “programación heroica” en la cual una sola persona pretende recordar todo lo relevante acerca del sistema. Pero en general esto es imposible.
    • Ingeniería de Software
      • ¿Cómo son los sistemas considerados buenos?
        • La evolución del entendimiento de un problema seria como sigue:
          • 1.- Los sistemas son muy complejos y no se puede centrar solo en el código cercano al cambio por realizar sino que se debe entender partes más lejanas.
    • Ingeniería de Software
      • ¿Cómo son los sistemas considerados buenos?
          • 2.- Un sistema es un conjunto de módulos y existen algunas dependencias entre ellos. En el sentido más general, un módulo puede ser cualquier “bit” identificable de un sistema por lo cual tiene sentido considerarlo en forma separada.
    • Ingeniería de Software
      • ¿Cómo son los sistemas considerados buenos?
          • Los módulos pueden ser:
            • Archivos
            • Subrutinas
            • Funciones de biblioteca
            • Clases, en un lenguaje orientado a objetos.
            • Otras partes conocidas como módulos o similares
            • Programas o subsistemas independientes o semi-independientes.
    • Ingeniería de Software
      • ¿Cómo son los sistemas considerados buenos? (cont.)
        • Características de los módulos para que el desarrollo y mantenimiento del sistema sea lo más fácil, barato y confiable posible:
          • dependencia (dependency)
          • cohesión (cohesion) Alta
    • Ingeniería de Software
      • ¿Cómo son los sistemas considerados buenos? (cont.)
          • interfase (interface) Definida
          • Encapsulación (encapsulation) Módulos
          • abstracción (abstraction)
          • Componente (component) Insertable, reusable
          • Acoplamiento (coupling) Bajo
    • Ingeniería de Software
        • Si El módulo A depende del módulo B si un cambio en el módulo B significa que el módulo A también necesita ser modificado.
        • La dependencia es conocida a veces como acoplamiento. Un sistema con muchas dependencias tiene un acoplamiento grande .
        • Los sistemas buenos tienen un acoplamiento bajo , porque los cambios a una parte del sistema son menos propensos a propagarse a través del sistema
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo
        • Queremos minimizar el numero de casos en los cuales un cambio a un módulo genera un cambio en otro módulo.
        • Tenemos que conocer cuales cambios dentro de un módulo pueden afectar el resto del sistema.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo
        • Para tomar ventaja del acoplamiento bajo de un sistema, es importante ser capaz de identificar cuales módulos están acoplados, de otra forma se tendrá que gastar esfuerzo verificando si hay que hacer cambios a un módulo, lo cual es un costo aún cuando no fue necesario el cambio. Nos gustaría tener certeza sobre los cambios.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo
        • Una vez que las fronteras entre los módulos de nuestro sistema están definidas, hay dos clases de información que puede ser útil:
          • 1.- ¿Qué suposiciones de un módulo dado pueden los clientes hacer acerca de él? Contestando, nos permitirá conocer que clase de cambios a un módulo pueden ser peligrosos (servicios que provee?)
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo
          • 2.- ¿Cuáles módulos son clientes de un módulo dado? Contestando, nos dice cuáles módulos tendrán que cambiar, si hacemos un cambio peligroso a un módulo.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
        • Interfases
          • Una interfase a un módulo define algunas características del módulo sobre las cuáles sus clientes pueden depender.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
        • Interfases
          • El resto del sistema solo puede usar el módulo en formas permitidas por las interfases; esto es, una interfase ENCAPSULA el conocimiento acerca de los módulos. “Las conexiones entre módulos son las suposiciones que hacen los módulos unos acerca de otros”
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
        • Interfases
          • Cualquier suposición que un cliente hace acerca de un servidor corre el riesgo de ser incorrecta; entonces debemos documentar tales suposiciones en interfases y verificar su validez.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
        • Interfases
          • Si documentamos bien todas las suposiciones en la interfase, seremos capaces de decir: “Si un módulo cambia internamente sin cambiar su interfase, este cambio no necesitará otros cambios en otras partes del sistema”.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
        • Interfases
          • Idealmente debería haber una verificación automática de que otros módulos no hacen suposiciones que no están documentadas en esta interfase, y también de que el módulo siempre justifica las suposiciones que están documentadas.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
        • Interfases
          • En un lenguaje de programación, mientras más permita que esas verificaciones sean automáticas, se dice que más soporta la modularidad y la encapsulación.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
        • Dependencias del contexto
          • Existen varias razones para querer conocer no solo qué dependencias pudieran existir (esto es, qué características están documentadas en las interfases de los módulos del sistema) sino también qué dependencias existen realmente.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
        • Dependencias del contexto
          • Sabemos que un cambio en un módulo puede afectar a sus clientes; sus clientes (por definición) son aquellos módulos que pueden necesitar un cambio, entonces es importante ser capaz de decir cuáles son ellos.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
        • Dependencias del contexto
          • Suponga que quiere reusar un módulo. Es necesario saber no solo qué servicios provee (cual es su interfase) sino también qué servicios requiere para trabajar. Los servicios que un módulo requiere son llamados sus dependencias de contexto . Ellos pueden a su vez ser expresados en términos de interfases; el módulo puede garantizar que si ciertas interfases le son provistas, entonces él a su vez proveerá sus propias interfases.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
        • Dependencias del contexto
          • Entre ellos, las dependencias de contexto de un módulo y la propia interfase del módulo garantiza que proveerá los servicios descritos en su interfase.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
        • Beneficios de la modularidad con interfases definidas.
          • Aún una interfase muy pobre para un módulo incorrectamente seleccionado puede hacer a un sistema más fácil de entender y modificar. Porqué?
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
          • Cualquier elemento que reduzca lo que tiene que ser conocido acerca de un módulo es benéfico en varias formas:
            • En un equipo de desarrollo, la gente desarrollando código que usa un módulo, solo deberá entender la interfase del módulo, no cómo trabaja, entonces serían más productivos.
            • Debido a que los desarrolladores pueden ignorar en forma segura algunos aspectos del sistema, tendrán un mejor entendimiento de los aspectos que sí necesitan conocer, entonces se introducirán menos errores.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
            • Los errores deberán ser más fáciles de encontrar (en desarrollo y mantenimiento), porque se evitará el examinar módulos irrelevantes.
            • Una vez que existe un módulo, con documentación de lo que provee y lo que requiere, es posible considerar reusarlo.
          • El reto real, es definir buenos módulos con las cosas correctas en sus interfases. Solo entonces se pueden lograr los beneficios completos.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
        • Un módulo puede tener varias interfases
          • A veces es necesario documentar los servicios que un módulo provee con varias y diferentes interfases, de un modo que podamos ser más precisos acerca de que servicios un cliente dado necesita. Esto es a la vez útil para el mantenimiento y para el reuso.
    • Ingeniería de Software
      • Encapsulamiento: Acoplamiento bajo (Cont.)
          • Ya tenemos una respuesta parcial a la pregunta de ¿Cómo son los sistemas considerados buenos?
        • Un buen sistema consiste de módulos encapsulados
    • Ingeniería de Software
      • Abstracción: Alta Cohesión.
        • Los buenos módulos tienen la propiedad de que sus interfases proveen una abstracción de alguna cosa que se entiende intuitivamente la cual sin embargo puede ser compleja de implantar. Tales módulos se dice que tienen una alta cohesión .
        • La interfase realiza una abstracción de las cosas que el desarrollador no tiene que entender para usar el módulo, dejando una figura coherente de lo que el usuario de un módulo quiere conocer.
    • Ingeniería de Software
      • Abstracción: Alta Cohesión.
        • El desarrollador está protegido de información irrelevante acerca de cómo el módulo hace lo que hace. Esta preocupación de permitir al desarrollador concentrarse en lo esencial es ligeramente diferente a la preocupación de encapsulación para lograr un acoplamiento bajo, lo cual va dirigido a la prevención de que el desarrollador use información escondida.
    • Ingeniería de Software
      • Abstracción: Alta Cohesión.
      • Abstracción es cuando un cliente de un módulo no necesita saber más de lo que está en la interfase.
    • Ingeniería de Software
      • Encapsulación es cuando un cliente de un módulo no es capaz de conocer más de lo que está en la interfase.
        • Si un módulo, de cualquier tamaño y complejidad, es una buena abstracción (tiene una alta cohesión y un acoplamiento bajo) puede ser factible de reusarlo en posteriores sistemas, o de reemplazo en sistemas ya existentes.
        • Estaríamos hablando de un componente insertable o conectable (“pluggable component”)
    • Ingeniería de Software
      • Arquitectura y componentes
        • La arquitectura donde se desarrolla y aquella dónde se va a usar.
        • En los 80s y principios de los 90s, la tecnología orientada a objetos iba a ser la solución a la crisis en desarrollo de software.
    • Ingeniería de Software
      • Arquitectura y componentes
        • Componente
          • Es una cosa que se puede reusar o reemplazar
        • Desarrollo Basado en Componentes (CBD, Component Based Development)
          • Un módulo con propiedades que lo hacen reusable y reemplazable.
    • Ingeniería de Software
      • Arquitectura y componentes
          • ¿Qué determina cuando un módulo es reusable?
            • Tiene una cohesión alta
            • Acoplamiento bajo con el resto del sistema
            • Interfase bien definida
            • Abstracción encapsulada de una cosa bien entendida
    • Ingeniería de Software
      • Arquitectura y componentes
          • Si un módulo es reusable depende del contexto en que se desarrolló y en el cual va a ser reusado.
          • Ejemplo de un factor no técnico de reuso: Recompensar al programador por el número de líneas que escriben.
          • Los factores técnicos involucran decisiones de arquitectura y más alto nivel.
    • Ingeniería de Software
      • Diseño basado en componentes: Insertabilidad, conectabilidad (pluggability)
        • La forma ideal de construir un nuevo sistema es tomar algunos componentes existentes y juntarlos.
    • Ingeniería de Software
      • Diseño basado en componentes: Insertabilidad, conectabilidad (pluggability)
        • Los componentes tienen que ser partes que llenan o cumplen necesidades en un sistema completo.
        • Las partes tienen que ser compatibles unas con otras y eso depende de la presencia de una arquitectura adecuada.
    • Ingeniería de Software
      • Diseño basado en componentes: Insertabilidad, conectabilidad (pluggability)
        • Las decisiones importantes acerca de la arquitectura:
          • Deben ser tomadas lo más pronto en el proyecto.
          • Son afectadas por la naturaleza de los componentes en la arquitectura
          • Pueden ser influenciadas por el medio ambiente del proyecto
    • Ingeniería de Software
      • ¿Cómo se construyen los buenos sistemas?
        • Usar un PROCESO definido con FASES claras, cada una de las cuales tiene un PRODUCTO FINAL (puede ser un documento o tal vez un prototipo)
    • Ingeniería de Software
      • ¿Cómo se construyen los buenos sistemas?
        • Preocuparse por cumplir con un conjunto claro de requerimientos, que se definen tan pronto como sea posible
        • Preocuparse por formas de verificación y validación, tan esenciales como construir el producto en sí mismo.
    • Ingeniería de Software
      • ¿Cómo se construyen los buenos sistemas?
        • Usar un almacén de CONOCIMIENTOS, ARQUITECTURAS y COMPONENTES relevantes.
        • Hacer un uso sensible de herramientas.
      • Proceso de desarrollo
        • Método tradicional para el desarrollo de Sistemas (Cascada / Waterfall)
      Ingeniería de Software Análisis Diseño Implementación Pruebas Mantenimiento
      • Proceso de desarrollo
        • Cada fase se realiza hasta que se completó la anterior. Supone que no se vuelve a entrar en las fases terminadas.
      Ingeniería de Software Análisis Diseño Implementación Pruebas Mantenimiento
    • Ingeniería de Software
      • Proceso de desarrollo
          • Administración de riesgos implica:
            • 1.- Cada vez que se toma una decisión se tiene el riesgo de que sea incorrecta. Mientras más se tarde en detectar un error más difícil es corregirlo. Evaluaciones frecuentes ayudan a corregir.
            • 2.- Un riesgo mayor es que los desarrolladores malinterpreten los requerimientos. La elaboración de prototipos permite reafirmarlos.
      • Proceso de desarrollo
        • Espiral de desarrollo:
        • Metodología Unificada.
          • Gran cantidad de metodologías orientadas a objetos han salido a la luz y las de Grady Booch, James Rumbaugh, Ivar Jacobson se unieron para formar el Lenguaje de Modelación Unificado (UML) y fue adoptado por el Object Management Group (OMG) como el estándar para cuestiones orientadas a objetos.
      Ingeniería de Software Análisis Diseño Construcción Transición
    • Bibliografía
      • Bibliografía
      Addison Wesley. Pearson. 1999 Martin Fowler con Kendal Scott UML gota a gota Prentice Hall. Pearson Educación. Tercera Edición. 1995 Kendall & Kendall Análisis y Diseño de Sistemas Prentice Hall. 1999 Craig Larman UML y Patrones. Introducción al análisis y diseño orientado a objetos. Cambridge University Press. 1998 James J. Odell Advanced Object-Oriented Analysis & Design Using UML Editorial Prentice Hall, Primera Edición 1999 Joseph Schmuller Aprendiendo UML en 24 Horas Sams Publishing, 2000 Matt Weisfeld The Object-Oriented Thought Process Addison Wesley. Updated Edition 2000. http://www.dcs.ed.ac.uk/home/pxs/Book/ Perdita Stevens, Rob Pooley Using UML. Software Engineering with objects and Components