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 SoftwarePara 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 SoftwareEl software se desarrolla, no se fabrica.Los costos del software se encuentran en la ingeniería.4

5. Fallos de Hardware5Fallos de desgasteFallos infantilesFallos normalesTaza de Fallos λTiempo t

6. Fallos de Software6Corrección de “bugs”Funcionamiento estableTaza de Fallos λTiempo t

7. Fallos Reales de Software ^_^!7Corrección de “bugs”Funcionamiento estableObsolescenciaCambioCambioCambioTaza de Fallos λCurva IdealCurva realTiempo t

8. Métodos y Herramientas para el Desarrollo de SoftwareEn 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 softwareEs todo el proceso que sigue el desarrollo de un producto de software.10Tiempo

11. Pasos Típicos de un Modelo de Ciclo de VidaInicialización /Planeación del SistemaAnálisis de Requerimientos y EspecificacionesEspecificaciones Funcionales o PrototipadoPartición y Selección (Construir VS comprar VS reutilizar)Diseño arquitectónico y Especificación de la ConfiguraciónEspecificación Detallada de Diseño de ComponentesImplementación de Componentes y Pruebas UnitariasIntegración de Componentes y PruebasRevisión de la Documentación y Entrega del SistemaDespliegue e InstalaciónEntrenamiento y UsoMantenimiento del Software11

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 EspecificacionesIdentifica 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 PrototipadoIdentifica 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ónDados 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ónDefine 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 ComponentesDefine 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 UnitariasCodifica las especificaciones en implementaciones operacionales de código fuente y valida su operación básica.18

19. Integración de Componentes y PruebasAfirma 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 SistemaEmpaquetar 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ónProporciona 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 UsoProporcionar 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 SoftwareMantener 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 SoftwareDescriptivoPrescriptivo24

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

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

27. Ciclo de Vida Lineal27Consiste 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álisisDiseñoImplementaciónPruebasInstalaciónAceptació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 simple28

29. Ciclo de Vida en Cascada29Es 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 siguienteRequerimientosAnálisisDiseñoImplementaciónPruebasOperaciones

30. Ciclo de Vida en V30Contiene 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álisisValidaciónMantenimientoDiseñoVerificaciónPruebasImplementación

31. Ciclo de Vida Iterativo31Iteración 1Iteración 2Iteración 3Es 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álisisAnálisisAnálisisDiseñoDiseñoDiseñoImplementaciónImplementaciónImplementaciónPruebasPruebasPruebasVersión 1Versión 2Versión 3

32. Ciclo de Vida Iterativo e Incremental32Este 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álisisAnálisisAnálisisDiseñoDiseñoDiseñoImplementaciónImplementaciónImplementaciónPruebasPruebasPruebas112123Versión 1Funcionalidad 1Versión 2+ Funcionalidad 2Versión 3+ Funcionalidad 3

33. MetodologíasSon 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.36Propone 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 trabajoHerramientas, modelos, y métodos que ayuden en el proceso de desarrollo37

38. Metodologías ÁgilesGeneralmente, 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 ÁgilValorar 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 plan40

41. Principios del Manifiesto ÁgilLa 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étricasEl manejo efectivo del proceso de desarrollo de software requiere medidas efectivas de ese procesoLas 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 software47

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

49. Métricas SimplesNúmero de líneas de códigoNúmero de páginas de documentaciónNúmero de horas-hombreNúmero de pruebasNúmero de requerimientos49

50. Métricas CompuestasLíneas de código por horas-hombreDefectos por cientos de líneas de códigoPáginas de documentación por cientos de líneas de código50

51. IndicadoresEl 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 indicadoresNúmero de tareas terminadas esperado vs número real de tareas terminadasNúmero de reportes de fallos escritos y resueltos contra el tiempoNúmero de cambios de requerimientos contra el tiempo52

53. Indicadores de CMMProgresoEsfuerzoCostoRevisiones de resultadosReportes de problemasEstabilidad de requerimientosUso de recursos computacionalesCapacitación53

54. Ejemplo de Grafico de Progreso54

55. ¿Alguna Pregunta?55

56. Gracias56http://www.javatutoriales.com/Java Tutoriales en Facebook