Tema 1 Introducción a la Ingeniería del Software. Marcos López Sanz Ingeniería del Software de Gestión

Transcripción

1 Tema 1 Introducción a la Ingeniería del Software Marcos López Sanz

2 Índice Introducción Qué es Software? Qué es Ingeniería del Software? Por qué surge la Ing. del SW? Crisis del Software Mitos del Software Malas prácticas de desarrollo y mantenimiento Lo que propone la Ing. del SW La complejidad inherente del software Algunos principios de la ingeniería del software Sistemas de Información

3 Introducción Qué es Software?

4 Introducción Qué es Software? Conjunto de programas que proporcionan una función y un rendimiento esperados Conjunto de estructuras de datos que permiten a los programas manipular adecuadamente la información Conjunto de documentos que describen el funcionamiento del SI (Sistema de Información). Tipos: Genéricos: Productos de uso genérico (procesadores, bases de datos, etc.) A medida: Productos específicos para un cliente particular

5 Introducción Qué es Software? Características: No tiene forma física Se desarrolla, no se fabrica Los costes del SW son de ingeniería. No de fabricación El SW no se rompe, se deteriora La complejidad del mantenimiento del SW es mucho más grande que la del HW Si el HW se rompe se cambia por otro y listo Hay piezas de recambio Si el SW se deteriora, con cada cambio que se realiza se deteriore aún más No hay piezas de recambio

6 Definición: Introducción Qué es Ingeniería del Software? La Ingeniería del Software es la disciplina de ingenieríaencargada de todos los aspectos relacionados con la producción de software desde sus etapas más tempranas de la especificación del sistema hasta el mantenimiento del sistema tras su puesta en marcha Ingeniería del Software Ian Sommerville

7 Introducción Qué es Ingeniería del Software? Disciplina de ingeniería Los ingenieros de software usan las herramientas, métodos y teorías para solucionar los problemas que aparecen Incluso teniendo en cuenta restricciones económicas y de organización Producción de software Planificación de proyectos Administración de proyectos software Procesos técnicos de desarrollo de software Dirección de proyectos

8 Introducción Por qué surge la Ing. del Software? Para superar la crisis del software y terminar con los mitos del software hasta ahora existentes Para acabar con las malas prácticas de desarrollo y mantenimiento de software llevadas a cabo por las empresas Crear software de calidad

9 Introducción Crisis del Software Dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables (Dijkstra 1968) Causas: Los proyectos no terminaban en plazo Los proyectos no se ajustaban al presupuesto inicial Software que no cumplía las especificaciones Código inmantenible que dificultaba la gestión y evolución del proyecto Consecuencias: Baja calidad del Software Tiempo y presupuesto excedido Confiabilidad cuestionable Altos requerimientos del personal para el desarrollo y el mantenimiento

10 Introducción Mitos del SW Sobre la gestión Mito La empresa ya dispone de unos estándares de trabajo y unos procedimientos de desarrollo establecidos y son conocidos por todos nuestros empleados Realidad En realidad muchas empresas no disponen de estándares ni procedimientos de trabajo y si los disponen, éstos son incompletos, no utilizan prácticas modernas de desarrollo, no todo el personal los conoce y nadie controla que éstos se apliquen.

11 Introducción Mitos del SW Sobre la gestión Mito El equipo de trabajo dispone de las más modernas herramientas de desarrollo y trabaja con las máquinas más potentes Realidad No sirve de nada trabajar con las mejores máquinas o utilizar las herramientas más modernas si el equipo no tiene los conocimientos necesarios para utilizarlas eficazmente (cursos de formación, soporte profesional externo )

12 Introducción Mitos del SW Sobre la gestión Mito Por qué hacer una planificación exhaustiva, si cometemos algún error, siempre podemos añadir gente Realidad Añadir gente nueva en un proyecto que está atrasado, lo hace atrasar aún más. Los nuevos integrantes deben integrarse, recibir formación y aprender la manera de comunicarse en el grupo.

13 Introducción Mitos del SW Sobre el cliente 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 inútil en software. Es esencial una descripción formal y detallada del ámbito de la información. Es necesaria una exhaustiva comunicación entre el cliente y el analista.

14 Introducción Mitos del SW Sobre el cliente 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 varia según en el momento que se presenten (Definición: Bajo Impacto / Desarrollo: Alto Impacto / Después de la entrega: Crítico Impacto)

15 Introducción Mitos del SW Sobre desarrolladores Mito No es necesaria ninguna metodología, cuanto antes empecemos a programar, antes acabaremos Realidad Cuando más pronto se comience a escribir código, más se tardará en terminarlo. Entre el 50% y el 70% de todo el esfuerzo dedicado a un programa se realizará después de que se la haya entregado al cliente por primera vez.

16 Introducción Mitos del SW Sobre desarrolladores Mito Lo único que realmente importa, cuando se termina un proyecto, es que la aplicación funcione. La documentación nadie la utiliza Realidad La documentación es la base de un desarrollo y, lo que es más importante, proporciona guías para la tarea de mantenimiento del software.

17 Introducción Malas prácticas de desarrollo y mantenimiento Planificación y estimaciones imprecisas: No se recopilan datos de proyectos pasados. Se invierte más dinero en mantenimiento que en formación de los ingenieros en las nuevas tecnologías de desarrollo. No se documenta lo suficiente. Se pasa directamente a la codificación.

18 Introducción Malas prácticas de desarrollo y mantenimiento Procesos software improvisados No se siguen rigurosamente las especificaciones No se hace planificación de riesgos Se resuelven crisis inmediatas Se apagan fuegos Se sacrifica funcionalidad y calidad del producto para cumplir plazos No se planifica debidamente No se realizan pruebas, verificaciones o revisiones del SW

19 Síntomas: Introducción Malas prácticas de desarrollo y mantenimiento Baja calidad del software desarrollado Alto grado de desconfianza e insatisfacción en el cliente Empresas inmaduras En fase artesanal Se exceden en los plazos y presupuestos previstos 90% de los proyectos no consiguen los objetivos propuestos 40% fracasan completamente 29% nunca se entregan

20 Introducción Qué propone la IS? ser Ingenieros! Artesano Ingeniero Para ello se debe: Aplicar métodos, técnicas y herramientas de desarrollo Adoptar estándares de desarrollo Utilizar la experiencia acumulada Documentación

21 Introducción Qué propone la IS? usar Estándares! Qué conseguimos adoptando estándares de desarrollo? Mejorar el proceso: Reducción de costes Reducción del tiempo de desarrollo Reducción de riesgos Mejora de la calidad del producto Protección del cliente Protección de la organización Aumenta su competitividad

22 Índice Introducción La complejidad inherente del software Complejidad del dominio del problema Controlar el proceso de desarrollo Caracterizar problemas discretos Algunos principios de la ingeniería del software Sistemas de Información

23 Complejidad del SW Por qué es complejo el Software? Brooks (1987): La complejidad del Software es una propiedad esencial y no accidental Complejidad accidental: se debe a la manera en que intentamos solucionar el problema Complejidad esencial: es inherente al problema en sí mismo Tres motivos: La complejidad del dominio del problema La dificultad de controlar el proceso de desarrollo Los problemas para caracterizar sistemas discretos

24 Complejidad del SW Complejidad del dominio del problema Los problemas del mundo real son complejos (miles de requisitos compitiendo y quizás contradictorios) Se añaden requerimientos no funcionales: eficiencia, coste, fiabilidad, robustez... Diferente perspectiva del mismo problema entre los usuarios y los desarrolladores Los requisitos cambian durante el desarrollo!

25 Complejidad del SW Controlar el proceso de desarrollo Surgen incidencias Algunas previstas y otras no Miles de líneas de código Intentar la reutilización Surgen diferentes versiones del producto Disminuir la complejidad mediante el divide y vencerás División en módulos Aún así, la creación de muchos módulos puede ser inmanejable

26 Complejidad del SW Caracterizar sistemas discretos El software trabaja con sistemas de estados discretos. Variables Flujos de control estado del sistema Eventos externos Cada evento externo puede cambiar el estado del sistema, pero se trata de un estado válido? Necesidad de pruebas Complejo, costoso y en ocasiones imposible que sean exhaustivas.

27 Índice Introducción La complejidad inherente del software Algunos principios de la ingeniería del software Sistemas de Información

28 Algunos principios de IS 1. Entregar el producto al cliente cuanto antes Se debe dedicar esfuerzo en la captura de las necesidades del cliente Captura de Requisitos Involucrar al cliente en el proceso de desarrollo Uso de Prototipos Respetar los plazos acordados con el cliente. Quedará satisfecho

29 Algunos principios de IS 2. Determinar el problema antes de escribir especificaciones Elegir la solución que mejor se adapte a las necesidades del cliente Analizar todas las posibles soluciones. Costes, esfuerzo, etc. No dar soluciones precipitadas. Explorar todas las alternativas

30 Algunos principios de IS 3. Minimizar la distancia intelectual Distancia intelectual: distancia entre el problema del mundo real y la solución computerizadadel problema (Dijkstra) Cuanto menor sea la distancia intelectual, más mantenible será el software. La estructura del SW debería ser cercana a la estructura del mundo real

31 Algunos principios de IS 4. Evaluar las alternativas de diseño Una vez establecidos los requisitos, qué arquitecturas o algoritmos elegir? Según por el diseño que optemos tendremos: Unos tiempos de respuesta u otros Más portabilidad Mayor seguridad

32 Algunos principios de IS 5. La técnica es más importante que las herramientas Un ingeniero software indisciplinado con una potente herramienta se puede convertir en un ingeniero peligroso Antes de seguir una herramienta, se debe comprender y seguir una técnica apropiada + = PELIGRO

33 Algunos principios de IS 6. Hazlo bien antes de hacerlo rápido Es más fácil hacer que un programa que funciona bien sea más rápido, que hacer que un programa rápido que funciona mal funcione bien. No preocuparse en optimizar en la fase inicial.

34 Algunos principios de IS 7. La inspección de código es mejor que la ejecución La inspección de código: Permite descubrir el 82% de los errores Consume cerca del 15% de los recursos disponibles para el desarrollo Reduce los costes de desarrollo entre un 25% y un 30% Reduce el tiempo de pruebas entre un 50% y un 90%

35 Algunos principios de IS 8. El personal es la clave del éxito Personal cualificado con herramientas insuficientes se puede llegar al éxito Personal NO cualificado con las más potentes herramientas, NO llegamos al éxito Importante trabajar en equipo Todo el personal debe conocer los estándares de trabajo Alguien debe controlar la aplicación de estos estándares Deberá haber una persona encargada de mantenerlos, adaptarlos y ampliarlos El equipo debe recibir cursos de formación

36 Algunos principios de IS 9. Un diseño sin documentación, NO es un diseño Los ingenieros de SW no competentes suelen decir: Ya he terminado el diseño, sólo falta la documentación. Os imagináis a un arquitecto que diga: el diseño del nuevo edificio ya está listo, sólo faltan los planos? Se debe ir documentando durante todo el proceso de desarrollo

37 Algunos principios de IS 10.El código difícil de leer es difícil de mantener. 11.La encapsulación crea SW fácil de probar y mantener Divide y vencerás 12.No probar tu propio SW. Los desarrolladores no deben probar el SW que han generado 13.La entropía de los sistemas aumenta. Cuanto más se modifica y crece un sistema SW, más complejo y desorganizado se vuelve

38 Índice Introducción La complejidad inherente del software Algunos principios de la ingeniería del software Sistemas de Información Qué es un sistema? Tipos y ejemplos Datos e información: qué es un sistema de información?

39 Qué es un Sistema? Es un conjunto de dos o más elementos interrelacionados que satisfacen las 3 propiedades siguientes: Cada elemento tiene influencia sobre el conjunto. No podemos quitar ninguno El comportamiento de cada elemento depende de los otros elementos del conjunto No hay un elemento aislable dentro del sistema La complejidad es una función que depende de: Nº elementos Nº de relaciones entre elementos

40 Ejemplos de Sistemas Sistema operativo

41 Ejemplos de Sistemas Sistema de transporte

42 Ejemplos de Sistemas Sistema planetario

43 Qué es un Sistema? Tipos Naturales Físicos: Estelares: sistema solar Geológicos: sistema ibérico. Biológicos: sistema nervioso. Vivientes: Animales: manadas. Creados por el hombre: Sociales: leyes, costumbres. De transporte: redes viales, líneas aéreas. De comunicación: Internet, teléfono, lengua. Financieros: Contabilidades, personal.

44 Qué son los Datos? Son los registros de los hechos, los acontecimientos o las transacciones Son la materia prima para obtener la información Son series de números, de caracteres que por si solos no quieren decir nada

45 Qué es Información? Son los datos procesadosde tal forma que resultan útiles o significativos en un cierto contexto. Según el proceso y según el contexto, la información puede resultar diferente

46 Qué es un Sistema de Información? Es un conjunto formal de procesos que operando sobre una colección de datos estructurados, según las necesidades de la empresa, recopilan, elaboran y distribuyen la información necesaria para las operaciones de esta empresa, y para las actividades de dirección y control correspondientes. De esta manera, la empresa puede llevar a cabo su actividad según su estrategia de negocio (Andreu et al., 1991)

47 Elementos a tener en cuenta en un Sistema de Información Procedimientos de trabajo La información: es la parte principal del sistema. Las personas o usuarios: son los que tratan la información. El equipo de soporte, para la comunicación, el procesamiento y el almacenaje de la información La parte física y tangible (HW, papel, servidores, soportes digitales )