La ingeniería de software es la disciplina que ofrece métodos y técnicas para desarrollar y mantener software de manera sistemática. Existen diferentes modelos de ciclo de vida como el lineal, en cascada e iterativo, los cuales dividen el proceso en etapas como análisis, diseño e implementación. También hay metodologías como Scrum que proveen guías para llevar a cabo los proyectos.

1. Ingeniería de Software

2. ¿Qué es la Ingeniería de Software? Es la disciplina o área de la ingeniería que ofrece métodos y técnicas para desarrollar y mantener software, que trata de sistematizar el proceso de desarrollo de software con el fin de minimizar el riesgo del fracaso. 2

3. Objetivos de la Ingeniería de Software Para lograr estos objetivos es necesario contar con estrategias de desarrollo de software que promuevan prácticas orientadas hacia la funcionalidad y la entrega. 3

4. Desarrollo de Software El software se desarrolla, no se fabrica. Los costos del software se encuentran en la ingeniería. 4

5. Fallos de Hardware 5 Fallos de desgaste Fallos infantiles Fallos normales Taza de Fallos λ Tiempo t

6. Fallos de Software 6 Corrección de “bugs” Funcionamiento estable Taza de Fallos λ Tiempo t

7. Fallos Reales de Software ^_^! 7 Corrección de “bugs” Funcionamiento estable Obsolescencia Cambio Cambio Cambio Taza de Fallos λ Curva Ideal Curva real Tiempo t

8. Métodos y Herramientas para el Desarrollo de Software En el desarrollo de un sistema es necesario hacer una planificación. Para ello se han desarrollado varias metodologías que tienen la intención de automatizar el proceso de desarrollo para que el producto resultante cumpla una serie de requisitos (tiempo de desarrollo, calidad, eficiencia, precio, mantenibilidad). 8

9. Métodos y Herramientas para el Desarrollo de Software (2) Las metodologías dividen la realización de un proyecto en una serie de etapas. A las distintas formas de ordenar el esfuerzo a lo largo del tiempo se les conoce con el nombre de ciclos de vida. 9

10. Modelos de ciclo de vida de desarrollo de software Es todo el proceso que sigue el desarrollo de un producto de software. 10 Tiempo

11. Pasos Típicos de un Modelo de Ciclo de Vida Inicialización /Planeación del Sistema Análisis de Requerimientos y Especificaciones Especificaciones Funcionales o Prototipado Partición y Selección (Construir VS comprar VS reutilizar) Diseño arquitectónico y Especificación de la Configuración Especificación Detallada de Diseño de Componentes Implementación de Componentes y Pruebas Unitarias Integración de Componentes y Pruebas Revisión de la Documentación y Entrega del Sistema Despliegue e Instalación Entrenamiento y Uso Mantenimiento del Software 11

12. Inicialización /Planeación del Sistema ¿De dónde viene el sistema? En la mayor parte de los casos, nuevos y mejores sistemas reemplazan o complementan mecanismos existentes informales. 12

13. Análisis de Requerimientos y Especificaciones Identifica los problemas que se supone serán resueltos por un nuevo sistema de software, sus capacidades operacionales, sus características de rendimiento, y la infraestructura de recursos necesitada para soportar la operación y el mantenimiento del sistema. 13

14. Especificaciones Funcionales o Prototipado Identifica y potencialmente formaliza los objetos, sus atributos y relaciones, las operaciones que transforman estos objetos, las restricciones que restringen el comportamiento del sistema, etc. 14

15. Partición y Selección Dados los requerimientos y las especificaciones funcionales, dividir el sistema en piezas manejables, que denoten subsistemas lógicos, entonces determinar si estas piezas corresponden con piezas nuevas, existentes, o reusables. 15

16. Diseño Arquitectónico y Especificación de la Configuración Define la interconexión e interfaces de recursos entre los subsistemas del sistema, componentes, y módulos en formas adecuadas para su diseño detallado y manejo completo de la configuración. 16

17. Especificación Detallada de Diseño de Componentes Define los métodos de procedimientos a través de los cuales los recursos de datos dentro de los módulos de un componente son transformados, de la entradas requeridas, a las salidas proporcionadas. 17

18. Implementación de Componentes y Pruebas Unitarias Codifica las especificaciones en implementaciones operacionales de código fuente y valida su operación básica. 18

19. Integración de Componentes y Pruebas Afirma y sustenta la integridad completa de la arquitectura del sistema a través de la verificación de la consistencia y la implementación completa de los módulos, verificando las interfaces de recursos e interconexiones contra sus especificaciones, y validar el rendimiento del sistema y de los subsistemas contra los requerimientos. 19

20. Revisión de la Documentación y Entrega del Sistema Empaquetar y describir el sistema desarrollado en documentos sistemáticos y guías de usuario, todas en una forma aceptable para su envío y soporte del sistema. 20

21. Despliegue e Instalación Proporciona instrucciones para instalar el software entregado en el ambiente local de computadoras, configurar los parámetros del sistema operativo y privilegios de acceso a los usuarios, y ejecutar casos de prueba de diagnostico para asegurar la viabilidad de las operaciones básicas del sistema. 21

22. Entrenamiento y Uso Proporcionar a los usuarios del sistema con ayudas instruccionales y guías para entender las capacidades y límites del sistema, para su uso de forma adecuada. 22

23. Mantenimiento del Software Mantener la operación útil del sistema en su ambiente proporcionando las mejoras propuestas de funcionalidad, reparaciones, mejoras de rendimiento, y conversiones. 23

24. Tipos de modelo de ciclo de vida de Software Descriptivo Prescriptivo 24

25. Modelos Descriptivos Describe la historia de cómo un sistema particular fue desarrollado. 25

26. Modelos Prescriptivos Prescriben cómo debe ser desarrollado un nuevo software. 26

27. Ciclo de Vida Lineal 27 Consiste en componer la actividad global del proyecto en etapas separadas que son realizadas de manera lineal, es decir, cada etapa se realiza una sola vez, a continuación de la etapa anterior, y antes de la etapa siguiente. Análisis Diseño Implementación Pruebas Instalación Aceptación

28. Ciclo de Vida Lineal (2) Las actividades de cada una de las etapas mencionadas deben ser independientes entre sí, es decir, no debe haber retroalimentación entre ellas, aunque si pueden admitirse ciertos supuestos de realimentación correctiva. Se puede tomar este ciclo de vida cuando algún sector pequeño de una empresa debe llevar un registro de datos acumulativos, sin necesidad de realizar procesos sobre ellos más que una consulta simple 28

29. Ciclo de Vida en Cascada 29 Es un ciclo de vida que admite iteraciones. Después de cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a la siguiente Requerimientos Análisis Diseño Implementación Pruebas Operaciones

30. Ciclo de Vida en V 30 Contiene las mismas etapas que el ciclo de vida en cascada. A diferencia de aquél, a este se le agregan dos sub-etapas de retroalimentación entre las etapas de análisis y el mantenimiento, y entre las etapas de diseño y pruebas. Análisis Validación Mantenimiento Diseño Verificación Pruebas Implementación

31. Ciclo de Vida Iterativo 31 Iteración 1 Iteración 2 Iteración 3 Es la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades del producto. Análisis Análisis Análisis Diseño Diseño Diseño Implementación Implementación Implementación Pruebas Pruebas Pruebas Versión 1 Versión 2 Versión 3

32. Ciclo de Vida Iterativo e Incremental 32 Este modelo de ciclo de vida se basa en la filosofía de construir incrementando las funcionalidades de la aplicación. Se realiza construyendo módulos que cumplen las diferentes funciones del sistema. Esto permite ir aumentando gradualmente las capacidades del software. Análisis Análisis Análisis Diseño Diseño Diseño Implementación Implementación Implementación Pruebas Pruebas Pruebas 1 1 2 1 2 3 Versión 1 Funcionalidad 1 Versión 2 + Funcionalidad 2 Versión 3 + Funcionalidad 3

33. Metodologías Son un modo sistemático de realizar, gestionar y administrar un proyecto para llevarlo a cabo con altas posibilidades de éxito. Indican cómo dividir un gran proyecto en módulos más pequeños, llamados etapas, y las acciones que corresponden a cada una de ellas. 33

34. Metodologías (2) Son un conjunto de pasos, guías, actividades y/o principios a seguir en una situación particular. Constituyen el manual o guía que se pone en práctica al construir un sistema. Ponen orden en todos los conceptos mencionados anteriormente: utilizan un ciclo de vida determinado y siguen las fases de especificación, diseño, etc., de un modo concreto. 34

35. Metodologías (3) Una metodología incluye: Reglas y Procedimientos. Métodos y Herramientas. Productos Resultantes. Normas de Calidad. Métricas. 35

36. ¿Por qué Necesitamos una Metodología? Es necesario saber cuándo se puede dar por concluida una tarea, quién debe realizarla, qué tareas preceden o anteceden a una tarea dada, qué documentación se usará para llevar a cabo la tarea, etc. 36 Propone un proceso disciplinado de desarrollo, con el fin de hacerlo más predecible y eficiente.

37. ¿Por qué Necesitamos una Metodología? (2) Proporciona un marco de trabajo que permite estructurar, planear, y controlar un proyecto de desarrollo. Este marco de trabajo consiste en dos partes: Una filosofía de trabajo Herramientas, modelos, y métodos que ayuden en el proceso de desarrollo 37

38. Metodologías Ágiles Generalmente, el proceso de desarrollo lleva asociado un marcado énfasis en el control del proceso mediante una rigurosa definición de roles, actividades, y artefactos, incluyendo modelado y documentación detallada. Este enfoque no resulta ser el más adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir los tiempos de desarrollo pero manteniendo un alto grado de calidad. 38

39. Metodologías Ágiles (2) Las metodologías ágiles cambian de forma significativa algunos de los procedimientos de los métodos tradicionales. Son menos orientados a documentos, exigiendo una cantidad más pequeña de documentación para una tarea dada. Estas metodologías son más orientadas al desarrollo, siguiendo un camino que sugiere que la parte importante de la documentación es el código. 39

40. El Manifiesto Ágil Valorar al individuo y las interacciones del equipo de desarrollo sobre los procesos y las herramientas. Desarrollar un software que funcione, más que conseguir una buena documentación. La colaboración con el cliente más que la negociación de un contrato. Responder a los cambios más que seguir estrictamente un plan 40

41. Principios del Manifiesto Ágil La prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor. Los requisitos cambiantes son bienvenidos, aún si llegan tarde al desarrollo. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. 41

42. Principios del Manifiesto Ágil (2) La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. 42

43. Principios del Manifiesto Ágil (3) El software que funciona es la medida principal de progreso. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. 43

44. Principios del Manifiesto Ágil (4) La simplicidad es esencial. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo y, según esto ajusta su comportamiento. 44

45. ¿Qué NO es Ágil? Algunos aprovechan el término ágil para referirse a cowboy programming(programación a lo vaquero), es decir, hacer lo que les viene en gana, como quieren y cuando quieren. Incluso hay empresas que creen estar siguiendo métodos ágiles pero que en realidad no lo hacen (y no saben que no lo hacen). 45

46. ¿Qué No es Ágil? (2) Existen mitos sobre el agilismo que dicen que no se documenta y que no se planifica. También se dice que no se necesitan arquitectos pero, no es cierto, lo que sucede es que las decisiones arquitectónicas se toman en equipo. El mal uso de la palabra ágil causa malas y falsas ideas sobre lo que verdaderamente es. 46

47. Métricas El manejo efectivo del proceso de desarrollo de software requiere medidas efectivas de ese proceso Las métricas de software son datos numéricos relacionados con el desarrollo de software. Las métricas soportan enormemente las actividades de la administración de proyectos de software 47

48. Métricas (2) Están relacionadas con las siguientes cuatro funciones de administración: Planeación Organización Control Mejoramiento 48

49. Métricas Simples Número de líneas de código Número de páginas de documentación Número de horas-hombre Número de pruebas Número de requerimientos 49

50. Métricas Compuestas Líneas de código por horas-hombre Defectos por cientos de líneas de código Páginas de documentación por cientos de líneas de código 50

51. Indicadores El término indicador es usado para denotar una representación de los datos de una métrica que da una idea del avance de un proyecto de desarrollo en curso, o de una actividad de mejora de un proceso. Los indicadores son métricas colocadas una forma accesible para la evaluación del comportamiento de un proyecto o un proceso de mejora. 51

52. Ejemplos de indicadores Número de tareas terminadas esperado vs número real de tareas terminadas Número de reportes de fallos escritos y resueltos contra el tiempo Número de cambios de requerimientos contra el tiempo 52

53. Indicadores de CMM Progreso Esfuerzo Costo Revisiones de resultados Reportes de problemas Estabilidad de requerimientos Uso de recursos computacionales Capacitación 53

54. Ejemplo de Grafico de Progreso 54

55. ¿Alguna Pregunta? 55

56. Gracias 56 http://www.javatutoriales.com/ Java Tutoriales en Facebook