Desarrollo de Software y Flujos

1. Desarrollo de Software y Flujos Diciembre 2008 Iván Párraga García ivan.parraga.garcia@gmail.com V1.1

2. Parte 1 Ingeniería del Software y Metodologías

3. Índice • El problema. ¿Por qué es tan difícil desarrollar software? • Arquitectura de Aplicaciones. ¿Cómo organizamos el caos? • Metodologías. ¿Pero no podemos empezar a programar directamente? • Entornos y herramientas. ¡Vamos a la guerra!

4. Módulo 1El Problema ¿Por qué es tan difícil desarrollar software?

5. ¿Qué vamos a ver? • La problemática de la construcción de software • La ingeniería del software como solución • Partes fundamentales de la ingeniería del software • Ciclos de vida de construcción de software

6. Crisis del Software • Término acuñado en 1968 en la 1ª conferencia sobre desarrollo de software organizada por la OTAN • “Dificultad en escribir programas libres de defectos, fácilmente comprensibles, y que sean verificables. Las causas son, entre otras, la complejidad que supone la tarea de programar y los cambios a los que se tiene que ver sometido un programa para ser continuamente adaptado a las necesidades de los usuarios” [Wikipedia]

7. Resultado Proyectos Informáticos Fuente: Oficina de Cuentas del G. Norteamericano, 1979 [GAO, 1979]

8. Problemas y Causas • Problemas • Proyectos fuera de plazo • Desajuste con el presupuesto • Baja calidad • No cumplir las especificaciones • Código no mantenible • Causas • Disciplina joven • Naturaleza del software • Complejidad • Gestión

9. ¿Solución? Ingeniería del software • “Trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales” (Bauer, 1972) • “Aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software” (Bohem, 1976) • “Es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software” (Zelkovitz, 1978) • “Aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software” (IEEE, 1993)

10. Un ingeniero… • Dispone de herramientas, técnicas y metodologías probadas • Se preocupa de la fiabilidad y el rendimiento • Reduce costes y complejidad • Realiza modelos y prototipos basados en teorías sólidas y estándar • Utiliza diagramas formales • Documenta de forma adecuada

11. Factores de calidad y conflictos

12. ¿Se garantiza el éxito? • Ingeniería todavía joven • Muchas metodologías diferentes y a veces contrapuestas • La industria todavía no se ha puesto de acuerdo sobre cuál es LA metodología • Aplicar una metodología y unas buenas prácticas, al menos garantizan una conciencia de lo qué se hace, permite tener unas métricas de calidad • La ausencia GARANTIZA el FRACASO

13. Ciclo de vida • Para obtener un producto software final se distinguen una serie de fases diferenciadas • El conjunto de estas fases, cómo se organizan y cómo se relacionan es lo que se conoce como el ciclo de vida del software • Existen diferentes ciclos de vida

14. Proceso Ingeniería – C. Vida Clásico Análisis Análisis Generación Especificación Selección Diseño Especificación Implementación Implementación Pruebas Mantenimiento Mantenimiento

15. Ciclo de vida: algunas definiciones • Análisis y toma de requerimientos (analistas) • Consiste en determinar qué ha de hacer el sistema • Especificación (analistas) • Formalización de los requerimientos • Diseño (arquitectos) • Elección de la arquitectura y planificación del sistema • Implementación (programadores) • Codificación del sistema • Testing (testers) • Verificación de que todo funcionar conforme a la especificación • Instalación (deployers) • Mantenimiento (explotación)

16. Ciclo de vida en cascada (I) • El más tradicional • No se empieza una fase hasta que ha acabado la anterior • Cada fase genera documentación que es la entrada de la siguiente • Cada fase puede tener personal especializado Análisis Especificación Diseño Implementación Pruebas Mantenimiento

17. Ciclo de vida en cascada (II) • Ventajas • Planificación “sencilla” • Calidad del producto • Permite trabajar con perfiles con grados de especialización (y sueldos) diferentes en cada fase • Inconvenientes • Normalmente los requerimientos nunca están al 100% bien definidos • Si ha habido errores, es difícil volver a una fase anterior • No hay producto hasta el final • Difícil determinar el progreso real • Lento • Mayor coste

18. Ciclo de vida iterativo (I) Análisis Análisis Especificación Especificación Diseño Diseño Implementación Implementación Pruebas Pruebas Versión 1 Versión 2

19. Ciclo de vida iterativo (II) • Ventajas • Planificación sencilla • Calidad del producto • Permite trabajar con personal poco cualificado en algunas etapas • Se tienen versiones antes de acabar el proyecto • Disminuye los problemas por toma de requerimientos incorrecta • Inconvenientes • No hay producto hasta el final • Difícil determinar el progreso real • Lento • Mayor coste

20. Prototipaje (I) • Se construye un prototipo antes de hacer el producto final • Útil cuando se usan nuevas tecnologías o que no se conocen o cuando los requerimientos son muy vagos • Permite evaluar si la solución adoptada es satisfactoria antes de implementar toda la funcionalidad

21. Prototipaje (II) Especificaciones incompletas Especificaciones completas Selección del prototipo Desarrollo del prototipo Evaluación del prototipo Fase de prototipado

22. Ciclo de vida evolutivo • Se usa en proyectos donde se van conociendo los requerimientos poco a poco • En cada iteración se implementa el requerimiento que se conoce • Al final de cada iteración tenemos una versión

23. Ciclo de vida en espiral • Conocemos todos los requerimientos al principio (no es evolutivo) • En cada iteración: • Planificación: selección de requerimientos • Análisis de riesgos • Implementación • Evaluación por parte del cliente

24. ¿Qué hemos visto? • En 1969 se acuñó el término Crisis del Software y nació el embrión de la ingeniería del software • La ingeniería del software es una disciplina joven pero madura que intenta superar la crisis del software • Un ingeniero tiene herramientas y métodos para solucionar problemas • Se definen diferentes ciclos de vida para construir software

25. Bibliografía • [Wikipedia] • http://en.wikipedia.org/wiki/Software_crisis • [GAO, 1979] Estudio de la Oficina de Cuentas del Gobierno de Estados Unidos sobre el desarrollo del software • Enginyeria del Software Especificació, DolorsCostat, M. Ribera Sancho, Ernest Teniente, Edicions UPC (2002)

26. Módulo 2Arquitectura de aplicaciones ¿Cómo organizamos el caos?

27. ¿Qué vamos a ver? • Componentes de un sistema • Evolución y tipos de arquitecturas • Patrones de diseño

28. ¿Arquitectura software? • Los diferentes subcomponentes de un sistema de información • Cómo se organizan y relacionan estos componentes

29. Tipos de componentes • Elementos de interfaz de usuario • Interacción con el usuario • Componentes de lógica de negocio • Implementan las funciones de la aplicación • Bases de datos • Persistencia fiable de datos • Conectores • Integración de sistemas diferentes • Protocolos • “Lenguajes” que utilizan los diferentes sistemas para comunicarse • Middleware • Es el “pegamento” que une todos los componentes en entornos distribuidos

30. Interfaces: consola • Las primeras interfaces eran todas así • Algunas sistemas las conservan por motivos históricos • Útiles para controlar dispositivos (routers, sensores, etc.) de manera remota

31. Tipos de interfaces: GUI • Las interfaces gráficas de cualquier sistema de ventanas actual • Hoy día, casi exclusivamente para aplicaciones de escritorio

32. Tipos de interfaces: web • El usuario sólo necesita un navegador web • Por tanto: independiente de la plataforma • Útil en entornos distribuidos

33. Lógica de negocio

34. Bases de datos • Se encargan de mantener la persistencia de la información • Son resistentes a caídas del sistema • Muchos productos pero lenguaje de interacción común y estandarizado: SQL

35. Conectores y protocolos • Permiten que (sub)sistemas y componentes de fabricantes diferentes puedan comunicarse Conector Conector Conector

36. Aplicación Screen Scrape Download Aplicación Cola de File Aplicación Screen Mensajes Aplicación Scrape Sockets Transaction Screen Transaction File Scrape File Aplicación Sockets CICS Gateway Download RPC ORB File APPC Aplicación Mensaje Aplicación ORB Cola de Aplicación Transaction Mensajes File Aplicación Cola de Mensajes CICS Gateway Screen Transaction Scrape File APPC Download Mensaje RPC Aplicación File Middleware • Es el software que integra, gestiona, arbitra todos los subsistemas en entornos distribuidos

37. Evolución de la arquitectura

38. Arquitec. HOST / Mainframe (I) • La persistencia de datos y la lógica de negocio integrados en la mismo servidor • El usuario tiene una terminal tonta (sin capacidad de proceso) que le conecta al servidor Terminales tontas Mainframe (datos y lógica de negocio)

39. Arquitec. HOST / Mainframe (II) Ventajas Inconvenientes • Administración sencilla de las terminales • Administración centralizada del servidor • Complicado modificar o añadir funcionalidades • Escalabilidad limitada: solo el mainframe procesa datos • Baja reutilización de código • Nula interconexión de sistemas

40. Arquitectura cliente / servidor (I) • Las máquinas de los usuarios tienen capacidad de cálculo y se comunican con un protocolo a medida con el servidor Ordenadores personales Servidor (datos y lógica de negocio)

41. Arquitectura cliente / servidor (II) Ventajas Inconvenientes • Se libera al servidor de carga de trabajo ya que los ordenadores del usuario pueden hacer parte del proceso • Cada vez que se modifica alguna funcionalidad en el servidor hay que actualizar todos los clientes • Complicado modificar o añadir funcionalidades (datos y lógica mezclados)

42. Arquitectura multicapa (I) • Sistemas especializados por tareas en los servidores • Los usuarios acceden mediante un navegador web estándar Presentación SGBD Lógica de Negocio

43. Arquitectura multicapa (II) Ventajas Inconvenientes • Mantenible • Sistemas separados por responsabilidades • Fácil añadir / modificar funcionalidades • Escalable: los diferentes subsistemas pueden dimensionarse independientemente • Mayor reusabilidad • Fácil gestión de las máquinas de los usuarios • Todavía es difícil integrarse con sistemas más allá de la empresa: no es un modelo B2B

44. Arquitectura Orientada al Servicio • SOA = Service Oriented Architecture • No tan nueva tecnología pero que esta en estado de madurez en la actualidad (está de moda)

45. SOA: ¿qué es un servicio? • Servicio: es un bloque funcional que responde a una necesidad de la organización • Por ejemplo: “dar de alta empleado” • Para usarlo se puede asumir: • Invocación remota • Interoperabilidad de plataformas diferentes • Independencia de plataforma

46. SOA: Necesidades actuales • Integración B2B (clientes / proveedores) • Incrementar la agilidad de los sistemas de información para que respondan igual de rápido que los cambios del negocio: reducir el time to market • Reutilizar las funcionalidades existentes • Crear nuevas funcionalidades • Independencia de plataforma (lenguajes y SO) • Datos y procesos distribuidos

47. Aplicación Screen Scrape Download Aplicación Cola de File Aplicación Screen Mensajes Aplicación Scrape Sockets Transaction Screen Transaction File Scrape File Aplicación Sockets CICS Gateway Download RPC ORB File APPC Aplicación Mensaje Aplicación ORB Cola de Aplicación Transaction Mensajes File Aplicación Cola de Mensajes CICS Gateway Screen Transaction Scrape File APPC Download Mensaje RPC Aplicación File SOA: La problemática existente • Las organizaciones han ido añadiendo sistemas de información a medida que los han necesitado • Para integrar los sistemas se han hecho conectores 1 a 1 • Resultado: un caos no mantenible

48. SOA: La solución • Los sistemas se ponen de acuerdo para “hablar” un único “idioma”: webservices • Sólo necesitamos conversores a este “idioma” • Además los servicios son reusables y exportables más allá de la organización • SOA da respuesta tecnológica al BPM (Business Process Management)

49. SOA: La foto

50. ¡Qué complicado! • Múltiples componentes: interfaces, bases de datos, conectores… • Múltiples arquitecturas posibles • Múltiples necesidades: satisfacer requerimientos, eficiencia, mantenibilidad, usabilidad… • Patrones al rescate