ACI491: Ingeniería de Software - PowerPoint PPT Presentation

aci491 ingenier a de software n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
ACI491: Ingeniería de Software PowerPoint Presentation
Download Presentation
ACI491: Ingeniería de Software

play fullscreen
1 / 73
ACI491: Ingeniería de Software
173 Views
Download Presentation
yoland
Download Presentation

ACI491: Ingeniería de Software

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. ACI491:Ingeniería de Software Unidad 5: Introducción a la Ingeniería de Software

  2. Contenidos • Importancia del software. • Impacto del software en los productos y servicios. • Crisis del software: Problemas y soluciones. • Ciclo de vida del software: paradigmas y fases genéricas. • Planificación de proyectos de software.

  3. Objetivos específicos • Conocer la importancia que tiene el software al interior de las organizaciones. • Ser capaz de identificar problemas y entregar las soluciones mas optimas para estos. • Identificar cuando es necesario una solución informática (software) y cuando no es necesaria. • Ser capaz de planificar un software, identificando claramente sus ciclo de vida.

  4. Introducción • Hoy en día el software tiene un doble papel: Es un producto y, al mismo tiempo, el vehículo para entregarlo. • Como producto, hace entrega de la potencia informática que incorpora el hardware informático o, más ampliamente, una red de computadoras que es accesible por hardware local. • Si reside dentro de un teléfono celular u opera dentro de una computadora central, el software es un transformador de información, produciendo, gestionando, adquiriendo, modificando, mostrando o transmitiendo información que puede ser tan simple como un solo bit, o tan complejo como una presentación en multimedia. • Como vehículo utilizado para hacer entrega del producto, el software actúa como la base de control de la computadora (sistemas operativos), la comunicación de información (redes) y la creación y control de otros programas (herramientas de software y entomos).

  5. Preguntas claves • ¿Por qué lleva tanto tiempo terminar los programas? • ¿Por qué son tan elevados los costes de desarrollo? • ¿Por qué no podemos encontrar todos los errores antes de entregar el software a nuestros clientes? • ¿Por qué nos resulta difícil constatar el progreso conforme se desarrolla el software?

  6. Tipos de software Una clasificación (Pressman) puede ser: • De sistema • De tiempo real • De gestión • De ingeniería y científico • Empotrado (embedded software) • De computadoras personales • Basado en la Web • De inteligencia artificial

  7. Crisis del software • Muchos observadores de la industria han caracterizado los problemas asociados con el desarrollo del software como una «crisis». • Más de unos cuantos libros han recogido el impacto de algunos de los fallos mas importantes que ocurrieron durante la década pasada. • No obstante, los mayores éxitos conseguidos por la industria del software han llevado a preguntarse si el término (crisis del software) es aún apropiado. • Robert Glass expone: «Puedo ver en mis ensayos históricos de fallos y en mis informes de excepción, fallos importantes en medio de muchos éxitos, una copa que está [ahora] prácticamente llena.»

  8. Crisis … (2) • El conjunto de problemas encontrados en el desarrollo del software de computadoras no se limitan al software que “no funciona correctamente”. • El mal abarca los problemas asociados a cómo desarrollar software, cómo mantener el volumen cada vez mayor de software existente y cómo poder esperar mantenemos al corriente de la demanda creciente de software. • Vivimos con esta aflicción desde este día - d e hecho, la industria prospera a pesar de ello. • Y así, las cosas podrán ser mejores si podemos encontrar y aplicar un remedio.

  9. Mitos • Muchas de las causas de la crisis del software se pueden encontrar en una mitología que surge durante los primeros años del desarrollo del software. • A diferencia de los mitos antiguos, que a menudo proporcionaban a los hombres lecciones dignas de tener en cuenta, los mitos del software propagaron información errónea y confusión.

  10. Mitos de gestión (1) • Mito. Tenemos ya un libro que está lleno de estándares y procedimientos para construir software, ¿no le proporciona ya a mi gente todo lo que necesita saber? • Realidad. Está muy bien que el libro exista, pero: ¿se usa?, ¿conocen los trabajadores su existencia?, ¿refleja las prácticas modernas de desarrollo de software?, ¿es completo?, ¿está diseñado para mejorar el tiempo de entrega mientras mantiene un enfoque de calidad? • En muchos casos, la respuesta a todas estas preguntas es NO.

  11. Mitos de gestión (2) • Mito. Mi gente dispone de las herramientas de desarrollo de software más avanzadas, después de todo, les compramos las computadoras más modernas. • Realidad. Se necesita mucho más que el último modelo de computadora grande o de PC para hacer desarrollo de software de gran calidad. Las herramientas de ingeniería del software asistida por computadora (CASE) son más importantes que el hardware para conseguir buena calidad y productividad, aunque la mayoría de los desarrolladores del software todavía no las utilicen eficazmente.

  12. Mitos de gestión (3) • Mito. Si fallamos en la planificación, podemos añadir más programadores y adelantar el tiempo perdido (el llamado algunas veces “concepto de la horda Mongol”). • Realidad. El desarrollo de software no es un proceso mecánico como la fabricación. Añadir gente a un proyecto de software retrasado lo retrasa aún más. Al principio, esta declaración puede parecer un contrasentido. Sin embargo, cuando se añaden nuevas personas, la necesidad de aprender y comunicarse con el equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo productivo. • Puede añadirse gente, pero sólo de una manera planificada y bien coordinada.

  13. Mitos del cliente • Un cliente que solicita una aplicación de software puede ser una persona del despacho de al lado, un grupo técnico de la sala de abajo, el departamento de ventas o una compañía exterior que solicita un software bajo contrato. • En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y desarrolladores del software hacen muy poco para corregir la mala información. • Los mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el que desarrolla el software.

  14. Mitos del cliente (2) • Mito. Una declaración general de los objetivos es suficiente para comenzar a escribir los programas. Podemos dar los detalles más adelante… • Realidad. Una mala definición inicial es la principal causa del trabajo baldío en software. Es esencial una descripción formal y detallada del ámbito de la información, funciones, comportamiento, rendimiento, interfaces, ligaduras del diseño y criterios de validación. Estas características pueden determinarse sólo después de una exhaustiva comunicación entre el cliente y el analista.

  15. Mitos del cliente (3) • Mito. Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible. • Realidad. Es verdad que los requisitos del software cambian, pero el impacto del cambio varía según el momento en que se introduzca. • Si se pone cuidado al dar la definición inicial, los cambios solicitados al principio pueden acomodarse fácilmente. • El cliente puede revisar los requisitos y recomendar las modificaciones con relativamente poco impacto en el coste.

  16. Impacto del cambio (1) Definición Desarrollo Después de la entrega

  17. Impacto del cambio (2) • Cuando los cambios se solicitan durante el diseño del software, el impacto en el coste crece rápidamente. Ya se han acordado los recursos a utilizar y se ha establecido un marco de trabajo del diseño. Los cambios pueden producir trastornos que requieran recursos adicionales e importantes modificaciones del diseño; es decir, coste adicional. • Los cambios en la función, rendimiento, interfaces u otras características, durante la implementación (codificación y prueba) pueden tener un impacto importante sobre el coste. • Cuando se solicitan al final de un proyecto, los cambios pueden producir un orden de magnitud más caro que el mismo cambio pedido al principio.

  18. Mitos de los desarrolladores (1) • Los mitos en los que aún creen muchos desarrolladores se han ido fomentando durante 50 años de cultura informática. Durante los primeros días del desarrollo del software, la programación se veía como un arte. Las viejas formas y actitudes tardan en morir. • Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado. • Realidad. Alguien dijo una vez: “cuanto más pronto se comience a escribir código, más se tardará en terminarlo”. Los datos industriales indican que entre el 60 y el 80 por ciento de todo el esfuerzo dedicado a un programa se realizará después de que se le haya entregado al cliente por primera vez.

  19. Mitos de los desarrolladores (2) • Mito. Hasta que no tengo el programa “ejecutándose”, realmente no tengo forma de comprobar su calidad. • Realidad. Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar la calidad del software: la revisión técnica formal. • La revisión del software es un “filtro de calidad” que se ha comprobado que es más efectivo que la prueba, para encontrar ciertas clases de defectos en el software.

  20. Mitos de los desarrolladores (3) • Mito. Lo único que se entrega al terminar el proyecto es el programa funcionando. • Realidad. Un programa que funciona es sólo una parte de una configuración del software que incluye muchos elementos. • La documentación proporciona el fundamento para un buen desarrollo y, lo que es más importante, proporciona guías para la tarea de mantenimiento del software.

  21. Primeras conclusiones • Muchos profesionales del software reconocen la falacia de los mitos descritos anteriormente. • Lamentablemente, las actitudes y métodos habituales fomentan una pobre gestión y malas prácticas técnicas, incluso cuando la realidad dicta un método mejor. • El reconocimiento de las realidades del software es el primer paso hacia la formulación de soluciones prácticas para su desarrollo.

  22. Resumen (1) • El software se ha convertido en el elemento clave de la evolución de los sistemas y productos informáticos. • En los pasados 50 años, el software ha pasado de ser una resolución de problemas especializada y una herramienta de análisis de información, a ser una industria por sí misma. • Pero la temprana cultura e historia de la “programación” ha creado un conjunto de problemas que persisten todavía hoy.

  23. Resumen (2) • El software se ha convertido en un factor que limita la evolución de los sistemas informáticos. • El software se compone de programas, datos y documentos. • Cada uno de estos elementos componen una configuración que se crea como parte del proceso de la ingeniería del software. • El intento de la Ingeniería del Software es proporcionar un marco de trabajo para construir software con mayor calidad.

  24. Ejercicios (1) • El software es la característica que diferencia a muchos productos y sistemas informáticos. Dé ejemplos de dos o tres productos y de, al menos, un sistema en el que el software, no el hardware, sea el elemento diferenciador. • En los años cincuenta y sesenta la programación de computadoras era un arte aprendido en un entorno básicamente experimental. ¿Cómo cree Ud. que ha afectado esto a las prácticas de desarrollo del software hoy? • Muchos autores han tratado el impacto de la “era de la información”. Dé varios ejemplos (positivos y negativos) que indiquen el impacto del software en nuestra sociedad. • Seleccione una aplicación específica e indique: (a) la categoría de la aplicación de software en la que encaje; (b) el contenido de los datos asociados con la aplicación; (c) la información determinada de la aplicación.

  25. Ejercicios (2) • A medida que el software se difunde más, los riesgos para el público (debido a programas defectuosos) se convierten en una preocupación cada vez más significativa. Desarrolle un escenario realista del juicio final (distinto a Y2K) en donde el fallo de computadora podría hacer un gran daño (económico o humano). • Lea detenidamente el grupo de noticias de Internet comp.risk y prepare un resumen de riesgos para las personas. Alternativa: Software Engineering Notes publicado por la ACM. • Escriba un papel que resuma las ventajas recientes en una de las áreas de aplicaciones de software principales. Entre las selecciones potenciales se incluyen: aplicaciones avanzadas basadas en Web, realidad virtual, redes neuronales artificiales, interfaces humanas avanzadas y agentes inteligentes. • Los mitos destacados en la presentación se están viniendo abajo lentamente a medida que pasan los años. Pero otros se están haciendo un lugar. Intente añadir un mito o dos mitos “nuevos” a cada categoría.

  26. ¿Qué es Ingeniería del Software? Una vuelta mas…

  27. Según Pressman • [La ingeniería del software] es el establecimiento y uso de principios robustos de la ingeniería a fin de obtener económicamente software que sea fiable y que funcione eficientemente sobre máquinas reales.

  28. Según Sommerville

  29. Según IEEE • El IEEE [IEE93] ha desarrollado una definición completa: Ingeniería del software: (1) La aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software; es decir, la aplicación de ingeniería al software. (2) El estudio de enfoques como en (1).

  30. ¿Qué es? • Cuando trabaja para construir un producto o un sistema, es importante seguir una serie de pasos predecibles: un mapa de carreteras (roadmap) que le ayude a obtener el resultado oportuno de calidad. • El mapa de carreteras a seguir es llamado “proceso del software”.

  31. El proceso del software (1) • Como el software, al igual que el capital, es el conocimiento incorporado, y puesto que el conocimiento está inicialmente disperso, el desarrollo del software implícito, latente e incompleto en gran medida, es un proceso social de aprendizaje. • El proceso es un diálogo en el que se reúne el conocimiento y se incluye en el software para convertirse en software.

  32. El proceso del software (2) • El proceso proporciona una interacción entre los usuarios y los diseñadores, entre los usuarios y las herramientas de desarrollo, y entre los diseñadores y las herramientas de desarrollo [tecnología]. • Es un proceso interactivo donde la herramienta de desarrollo se usa como medio de comunicación, con cada iteración del diálogo se obtiene mayor conocimiento de las personas involucradas.

  33. ¿Quién lo hace? • Los ingenieros de software y sus gestores adaptan el proceso a sus necesidades y entonces lo siguen. • Además las personas que han solicitado el software tienen un papel a desempeñar en el proceso del software.

  34. Importancia ¿Por qué es importante? • Porque proporciona estabilidad, control y organización a una actividad que puede, si no se controla, volverse caótica. ¿Cuáles son los pasos? • A un nivel detallado, el proceso que adoptemos depende del software que estamos construyendo. • Un proceso puede ser apropiado para crear software de un sistema de aviación, mientras que un proceso diferente por completo puede ser adecuado para la creación de un sitio Web.

  35. ¿Cuál es el producto obtenido? • Desde el punto de vista de un ingeniero de software, los productos obtenidos son: • programas, • documentos y • datos que se producen como consecuencia de las actividades de ingeniería del software definidas por el proceso.

  36. Calidad ¿Cómo puedo estar seguro de que lo he hecho correctamente? • Hay una cantidad de mecanismos de evaluación del proceso del software que permiten a las organizaciones determinar la “madurez” de su proceso del software. • Sin embargo, la calidad, oportunidad y viabilidad a largo plazo del producto que está construyendo son los mejores indicadores de la eficiencia del proceso que estamos utilizando.

  37. La Ingeniería del software es un tecnología multicapa (1) • El fundamento de la ingeniería del software es la capa de proceso. • El proceso de la ingeniería del software es la unión que mantiene juntas las capas de tecnología y que permite un desarrollo racional y oportuno de la ingeniería del software.

  38. La Ingeniería del software - tecnología multicapa (2) - proceso • El proceso define un marco de trabajo para un conjunto de áreas clave de proceso (ACPs) que se deben establecer para la entrega efectiva de la tecnología de la ingeniería del software. • Las áreas claves del proceso forman la base del control de gestión de proyectos del software y establecen el contexto en el que se aplican los métodos técnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se asegura la calidad yel cambio se gestiona adecuadamente.

  39. La Ingeniería del software - tecnología multicapa (3) - métodos • Los métodos de la ingeniería del software indican “cómo” construir técnicamente el software. • Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. • Los métodos de la ingeniería del software dependen de un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas.

  40. La Ingeniería del software - tecnología multicapa (4) - herramientas • Las herramientas de la Ingeniería del software proporcionan un enfoque automático o semiautomático para el proceso y para los métodos. • Cuando se integran herramientas para que la información creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniería del software asistida por computadora (CASE).

  41. Una visión general de la ingeniería del software • La ingeniería es el análisis, diseño, construcción, verificación ygestión de entidades técnicas (o sociales). • Con independencia de la entidad a la que se va a aplicar ingeniería, se deben cuestionar y responder las siguientes preguntas:

  42. Preguntas • ¿Cuál es el problema a resolver? • ¿Cuáles son las características de la entidad que se utiliza para resolver el problema? • ¿Cómo se realizará la entidad (y la solución)? • ¿Cómo se construirá la entidad? • ¿Qué enfoque se va a utilizar para no contemplar los errores que se cometieron en el diseño y en la construcción de la entidad? • ¿Cómo se apoyará la entidad cuando usuarios soliciten correcciones, adaptaciones y mejoras de la entidad?

  43. Fases – Fase de definición • El trabajo que se asocia a la ingeniería del software se puede dividir en tres fases genéricas, con independencia del área de aplicación, tamaño o complejidad del proyecto. • Cada fase se encuentra con una o varias cuestiones de las destacadas anteriormente. • La fase de definición se centra sobre el qué. Es decir, durante la definición, el que desarrolla el software intenta identificar qué información ha de ser procesada, qué función y rendimiento se desea, qué comportamiento del sistema, qué interfaces van a ser establecidas, qué restricciones de diseño existen, y qué criterios de validación se necesitan para definir un sistema correcto.

  44. Continuación… • Por tanto, han de identificarse los requisitos clave del sistema y del software. • Aunque los métodos aplicados durante la fase de definición variarán dependiendo del paradigma de ingeniería del software (o combinación de paradigmas) que se aplique, de alguna manera tendrán lugar tres tareas principales: • ingeniería de sistemas o de información, • planificación del proyecto del software y • análisis de los requisitos.

  45. Fases – fase de desarrollo • La fase de desarrollo se centra en el cómo. Es decir, durante el desarrollo un ingeniero del software intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función dentro de una arquitectura de software, cómo han de implementarse los detalles procedimentales, cómo han de caracterizarse interfaces, cómo ha de traducirse el diseño en un lenguaje de programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba. • Los métodos aplicados durante la fase de desarrollo variarán, aunque las tres tareas específicas técnicas deberían ocurrir siempre: • diseño del software, • generación de código y • prueba del software.

  46. Fases – Mantenimiento (1) • La fase de mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. • Durante la fase de mantenimiento se encuentran cuatro tipos de cambios: • Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra los defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos.

  47. Fases – Mantenimiento (2) • Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (por ejemplo: CPU, el sistema operativo, las reglas de empresa, las características externas de productos) para el que se desarrolló el software. El mantenimiento adaptativo produce modificación en el software para acomodarlo a los cambios de su entorno externo. • Mejora. Conforme se utilice el software, el cliente/ usuario puede descubrir funciones adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales.

  48. Fases – Mantenimiento (3) • Prevención. El software de computadora se deteriora debido al cambio, y por esto el mantenimiento preventivo también llamado reingeniería del software, se debe conducir a permitir que el software sirva para las necesidades de los usuarios finales. En esencia, el mantenimiento preventivo hace cambios en programas de computadora a fin de que se puedan corregir, adaptar y mejorar más fácilmente.

  49. Actividades protectoras • Las actividades de protección se aplican a lo largo de todo el proceso del software: • Seguimiento y control del proyecto de software. • Revisiones técnicas formales. • Garantía de calidad del software. • Gestión de configuración del software. • Preparación y producción de documentos. • Gestión de reutilización. • Mediciones. • Gestión de riesgos