Ingeniería de Software

1. Ingeniería de Software Métricas / Ciclos de vida

2. Métricas • ¿Porqué? “Cuando puedas medir lo que está diciendo y expresarlo con números, ya conoces algo sobre ello; cuando no puedas medir, cuando no puedas expresar lo que dices con números, tu conocimiento es precario y deficiente.”(Lord Kelvin)

3. Métricas • ¿Para qué sirve? • Medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado (IEEE Standard Glossary of Software Engineering, 1993) • Se aplican a: • Procesos (métricas de control): por ejemplo, tiempo y esfuerzo medios necesarios para corregir un error. • Productos (métricas de predicción): complejidad ciclomática de un módulo, número de métodos y atributos asociados con los objetos de un diseño,... • Permiten tomar decisiones • No se deben utilizar para sancionar empleados, sino para definir procesos de mejora (training, beneficios nuevos, motivación, etc.)

4. Métricas – Proceso general • Seleccionar métricas • Realizar la medición • Generar reportes de resultados • Analizar los valores y proponer acciones correctivas si son necesarias • Proveer feedbacka los stakeholders

5. Métricas - Tipos • Métricas del producto (Atributos de calidad) • Estáticas • Reusabilidad • Cantidad de clases • Complejidad ciclomática • Dinámicas • Performance • Cantidad de bugs encontrados • Métricas del proceso • Sobre tiempo • Sobre recursos • Sobre impacto de cambios

6. Selección de Métricas – GQM • GoalQuestionMetric es una metodología de definición de métricas, que especifica pasos basados en el hecho que para poder hacer mediciones útiles, primero debe definir qué objetivos tienen las mismas.Define un conjunto de pasos y buenas prácticas para definir dichas métricas

7. GQM - Pasos • Conceptual level (GOAL): Un Goal se puede definir de acuerdo a su objeto, a los stakeholders involucrados y al contexto particular. Tipos de objetos a medir son: • Productos: Software, código fuente, documentación, entregables en general. • Procesos: Los procesos involucrados en el análisis, desarrollo, testing, etc. • Recursos: HW, SW, espacio de trabajo, personal involucrado • Operationallevel (QUESTION):  Un conjunto de preguntas para cada goal, las cuales se utilizan para conocer el estado actual con respecto a una medida de calidad desde la perspectiva necesaria. • Quantitativelevel (METRIC): Se definen métricas, las cuales permiten medir de manera cuantitativa ciertas medidas de calidad para responder las preguntas dadas. Las métricas pueden ser: • Objetivas: no dependen del punto de vista: Cantidad de clases, Complejidad ciclomática • Subjetivas: atractividad del software, entendibilidad del código

8. GQM - Pasos • Conceptual level (GOAL): Un Goal se puede definir de acuerdo a su objeto, a los stakeholders involucrados y al contexto particular. Tipos de objetos a medir son: • Productos: Software, código fuente, documentación, entregables en general. • Procesos: Los procesos involucrados en el análisis, desarrollo, testing, etc. • Recursos: HW, SW, espacio de trabajo, personal involucrado • Operationallevel (QUESTION):  Un conjunto de preguntas para cada goal, las cuales se utilizan para conocer el estado actual con respecto a una medida de calidad desde la perspectiva necesaria. • Quantitativelevel (METRIC): Se definen métricas, las cuales permiten medir de manera cuantitativa ciertas medidas de calidad para responder las preguntas dadas. Las métricas pueden ser: • Objetivas: no dependen del punto de vista: Cantidad de clases, Complejidad ciclomática • Subjetivas: atractividad del software, entendibilidad del código

9. GQM - Goals • Se debe definir a nivel organizacional los goals que se quieren alcanzar. • Tipos de goals • Estratégicos: A largo plazo. Por ejemplo? • Tácticos: A nivel de proyecto

10. GQM - Goals • Se definen a partir de atributos que se desean mejorar. GQM propone un conjunto de atributos para definir mejor un Goal. • Atributos de un goal • Propósito: Se definen especificando qué se desea hacer, con respecto a qué • Punto de vista: desde la perspectiva de quién se busca • Contexto: El contexto que lleva a tal necesidad o información pertinente al goalEjemplos: • Goal 1: • Propósito: Mejorar velocidad de resolución de incidentes • Punto de vista: Del punto de vista del PM • Contexto: Proyecto nuevo con muchos incidentes • Goal 2: • Propósito: Analizar la complejidad de las interfaces con otros sistemas • Punto de vista: Equipo de desarrollo • Context: Proyecto nuevo con hecho orientado a objectos

11. GQM - Questions • A cada Goal se le asigna un conjuntos preguntas que permiten conocer cómo estamos con respecto a ese goal y qué falta hacer para conseguirlo. • Por ejemplo: • Goal 1: • ¿Cuánto se tarda actualmente en arreglar un incidente? • ¿Qué tipos de incidentes tardan más? • ¿Se mejoró con respecto a versiones anteriores? • Goal 2: • ¿Qué cantidad de interfaces existen? • ¿Cada cuánto cambian? • ¿Qué porcentaje son interfaces de objetos java, de mensajería, etc.?

12. GQM - Métricas • Para cada Goal se define una o más métricas que permiten responder a esa pregunta de manera cuantitativa • Goal 1: • Cuánto se tarda actualmente en arreglar un incidente? • Incidentes arreglados por día • Vida promedio de los incidentes • Comparación con iteraciones anteriores • Goal2: • Cada cuánto cambian? • Cambios requeridos en las itnerfaces por iteración • Evolución de la cantidad de cambios

13. Recolección de datos • Recolección de datos • Se debe definir el proceso de recolección de datos. • Teniendo en cuenta el objetivo de los goals que requieren dichas métricas se define: • Quién va a recolectar los valores? • si se va a hacer automáticamente o manualmente • Cuándo se va  a recolectar? • De acuerdo a los recursos con los que se cuenta, se define cuando se va a recolectar la información • Cómo se va a recolectar los datos? • Se define si se hace de manera automática, qué herramientas se cuentan, se debe “molestar” lo menos posible a las personas relacionadas con dichas métricas. • Quiénes son los principales stakeholders? • Teniendo en cuenta la perspectiva y los stakeholders se pueden obtener mejor subjetividad al mostrar los resultados.

14. Elaboración de reporte de resultados • Se elaboran reportes con los resultados utilizando gráficos: • de torta • de línea • histogramas • cuadros comparativos • diagramas de tendencia.

15. Reporte - Ejemplo

16. Análisis de resultados • Se deben verificar los reportes y analizar las posibles causas • Se puede utilizar el diagrama espina de pescado para analizar las causas • Se deben especificar acciones para mejorar

17. Comunicación de resultados • Se debe dar feedback a los diversos stakeholders sobre los resultados, describiendo: • Métricas utilizadas y resultados obtenidos • Reportes • Evaluación de causas y planes de acción

18. Ejemplos

19. Ejemplos

20. Ejemplos

21. Ejemplos • Goal: Analyze the delivered product for the purpose of understanding, with respect to the effectiveness of reuse, and from the viewpoint of the software development team in the context of Project A. • What is the percentage of modules that were not developed from scratch (i.e., some portion is reused [overall and per subsystem])? • Metric 1. For each software module: Developed from scratch (yes, no)? • Metric 2. For each software module: Name of subsystem it belongs to • What is the percentage of completely reused code (overall and persubsystem)? • Metric 1. For each software module: Code reused (yes, no)? • Metric 2. For each software module: Name of subsystem it belongs to

22. Ejemplos (Cont.) • Goal: Analyze the delivered product for the purpose of understanding, with respect to the effectiveness of reuse, and from the viewpoint of the software development team in the context of Project A. • For software modules where code is reused: What is the distribution of modules among reuse modification classes (overall and per subsystem)? • Metric 1. Degree of code modification (unchanged, mainly deletions, less than 20 percent of lines changed, more than 20 percent of lines changed) • Metric 2. Name and version of the original reused module • Metric 3. Name and version of the released reusing module • Metric 4. Name of subsystem it belongs to • What is the relationship between module reuse and reliability? • Metric 1. For all modules: What is the level of reuse? • Metric 2. For top faulty modules: What is the level of reuse? • Metric 3. For top non-faulty modules: What is the level of reuse? • Metric 4. For all modules: What is the fault density? • Metric 5. For reused modules: What is the fault density? • Metric 6. For non-reused modules: What is the fault density?

23. Ejemplos (Cont.) • Some conclusions were: • Reusing large parts of a module that is already fixed results in significantly lower faults than if developed from scratch • Faults in reused modules are detected more before delivery because reused modules are reviewed and tested more intensively than newly developed modules

24. Ciclos de vida Descansemos un rato 

25. Procesos de software / ciclos de vida • Es el conjunto de actividades requeridas, en un orden determinado, para desarrollar un Software. • Los tipos de actividades, entre otros, son: • Especificación de requerimientos • Diseño • Desarrollo • Validación • Evolución

26. Procesos de software / ciclos de vida • Cada actividad además tiene un conjunto de: • Roles necesarios • Condiciones necesarias (para iniciar y para terminar) • Dependiendo del proceso, existen diversas herramientas y metodologías aplicadas.

27. Modelos de Ciclos de vida • Un modelo de proceso es una representación abstracta del proceso. • Representa una descripción  del proceso que permite conocer qué actividades y metodologías se utilizaron, en qué orden y a qué nivel. • Se conocen varios modelos de proceso, que se pueden adaptar de acuerdo a las necesidades y que fueron adaptándose en los últimos años.

28. Modelos de Ciclos de vida • Esos modelos se pueden dividir en: • Orientados a planeamiento: • RUP • Cascada • Entrega en etapas • Orientados a adaptación al cambio: • Agile • Prototipado evolutivo • Orientados a disminuir riesgos: • Spiral • Orientados al tiempo: • Entrega evolutiva • Timebox • De acuerdo a las necesidades, un proceso puede tomar cosas de más de un modelo o incluso tomar distintos modelos para distintas etapas.

29. Cómoelegir un modelo? • Algunas preguntas: • Se requiere mucha documentación detallada o contrato muy rígido? • Se tiene seguridad con respecto a los requerimientos? • Se puede vender el proyecto, en lugar de como producto, como servicio? • Es muy grande el proyecto? Tiene equipos en distintos lugares del mundo? • Qué tipo de sistema se requiere? • Qué tipo de cliente se tiene? • Cuál es la expectación de vida del sistema a realziar? • Qué tecnologías se tienen al alcance y cuántos recursos se tienen para acceder a tecnologías pagas? • Se puede mover la fecha de finalización? • Qué tan experto es el equipo? • Qué tan riesgoso es el proyecto? • Cuánta visibilidad se necesita dar?

30. Qué pasa si no hay modelo?

31. Code And Fix • Se trata de un modelo en el que, una vez que se tiene una idea de lo que hay que hacer se empieza a desarrollar, cada cambio pedido se realiza directo en el código, etc. • En conclusión no se agrega ningún nivel de proceso. Simplemente, el o los programadores se sientan a programar.

32. Code And Fix • Ventajas • No se requiere mucha experiencia • Para proyectos muy chicos presenta resultados rápidamente: • prototipos que se planea descartar • pruebas de concepto • demos • Es fácil de aprender  no hay que hacer nada • Es fácil de implementar en equipos de una persona: • no hay equipo

33. Code And Fix • Desventajas • Si es un equipo, ya siquiera con 2 personas puede llegar a un caos: • ninguno sabe lo que hizo el otro • se pisan los cambios • se pierde conocimiento de los cambios que se fueron haciendo y por qué • no se conocen los tiempos totales, ni los costos • no se conocen los riesgos • el testing no existe o es exploratorio

34. Modelos basados en planeamiento • Son modelos con etapas que deben estar definidas de antemano • Cada etapa tiene una salida definida de manera precisa y completa • La salida se utilizará como entrada para la etapa siguiente. • Son los modelos más clásicos, están basados en otras disciplinas

35. Waterfall

36. Waterfall • Se definen ciertas etapas • Las mismas deben estar terminadas antes de avanzar a la siguiente • La salida de dicha etapa no se puede cambiar y va a ser utilizada como input para la etapa siguiente • En caso que el resultado de la etapa sea inválido se debe elegir cómo seguir • volver a realizar la etapa • extenderla • cancelar el proyecto.

37. Waterfall • Ventajas: • En proyectos largos ayuda a conocer el largo total del proyecto y ayuda a calcular el costo total del proyecto en etapas tempranas. • Cuando hay pocos cambios, la eficiencia es óptima. • Al final de cada etapa se tiene, en teoría, información precisa como para poder trabajar en la etapa siguiente. • El personal encargado de una etapa puede pasar a otro proyecto al terminar la misma

38. Waterfall • Desventajas: • Si bien ayuda a calcular el costo total, esto no toma en cuenta los cambios en los requerimientos. • Al tener una documentación excesiva, la eficiencia decrece dado que el personal trabaja en: • diseñar partes muy pequeñas del sistema • documentar requerimientos que luego no se harán • Incapacidad de reaccionar a los cambios.

39. Waterfall - variantes • Overlapped Waterfall

40. Waterfall - variantes • Sub-project Waterfall

41. RUP (Rational Unified Process) • Es un proceso desarrollado bajo una patente de Rational • Está relacionado integramente con UML (UnifiedModelingLanguage) • Busca integrar modelos existentes de manera de ser orientado a: • Riesgos • Planificación • Incrementalidad • Se definen 4 fases: • Inception • Elaboration • Construction • Transition

42. Rational Unified Process • En cada fase se desarrollan, en paralelo, distintos tipos de actividad que en Cascada, por ejemplo, se desarrollaban en secuencia. • RUP define actividades (Workflows): • Modelado de negocio • Ingeniería de requerimientos • Análisis y diseño • Implementación • Testing • Distribución • Configuración y evolución • Manejo de proyecto • Contexto y herramientas

43. Rational Unified Process • De acuerdo a la fase, cada actividad se realiza en distinto nivel:

44. BuenasPrácticas • Rup define un conjunto de buenas practicas: • Desarrollo Iterativo e incremental • Se planifican Iteraciones en las que cada una propone un incremento con respecto a la anterior, el cual es visible y medible • De ésta manera se reducen riesgos al dar más visibilidad del avance • Orientado a casos de uso • Los requerimientos se escriben en forma de casos de uso, y estos deben ser mantenidos en el tiempo (cambios) y su avance es visible • Se utilizan herramientas de control de cambio y configuración. • De esta manera se aumenta la visibilidad y se mejora la adaptación al cambio • Orientados a la arquitectura • Lo primero que se debe definir es la arquitectura • De esta manera se reducen riesgos de nivel técnico • Basado en UML • “Todos” conocen UML por lo que mejora la transmisión de conocimiento

45. Rational Unified Process • Es un modelo claro que permite establecer un balance entre el nivel de planificación, el manejo de riesgos y la adaptación al cambio • Utiliza herramientas de modelado (UML) que son conocidas mundialmente • Está ampliamente ligado a herramientas Case (Rational Rose) por lo que, al menos en teoría permite disminuir el nivel de codificación necesario • Define herramientas que deben ser utilizadas como control de versiones y configuración.

46. Rational Unified Process • Desventajas • Caro de implementar: se requiere personal capacitado en RUP, si se hace bien se debe acreditar dicha capacidad • Se debe implementar completo, se implementa RUP completo, sus prácticas por separado no son RUP • Las herramientas utilizadas en general son provistas por Rational y son caras • Agrega mucho overhead al proyecto

47. ModelosÁgiles • También conocidos como Rapid ApplicationDevelopment (RAD) • Son modelos de proceso que están de moda actualmente. • Se basan en que los clientes puedan tener de manera rápida el acceso del software, y que la reacción al cambio sea la prioridad. • Las actividades de desarrollo, análisis, diseño y testing se suelen hacer en paralelo • Se realizan iteraciones cortas que permiten una visibilidad rápida a los stakeholders • Se suele tener representantes de los clientes trabajando en conjunto con el equipo de desarrollo • Aparecieron luego de sucesivas fallas en procesos clásicos de desarrollo y por el “disgusto” que ocasionaba el alto overhead de los procesos.

48. ModelosÁgiles • Buenas prácticas • Enfocarse en el código, perdiendo énfasis la documentación • Desarrollo iterativo e incremental, con iteraciones cortas de alta visibilidad • Se tiene software funcional de manera temprana, lo que permite direccionar las expectativas de los clientes • El software evoluciona a partir del feedback de los clientes

49. Diferencias entre proceso clásicos y ágiles • Énfasis en las personas y sus interacciones vs procesos y herramientas: • Énfasis en las habilidades y conocimientos de las personas • Se busca mejorar el potencial de las mismas, en lugar de estar atado a un proceso • Énfasis en software andando vs documentación • Se tiene software andando, desarrollando en incrementos y desarrollando primero los requerimientos más importantes, en lugar de entregar documentación. • Énfasis en colaboración con usuarios vs contratos rígidos • Los usuarios/clientes colaboran durante todo el desarrollo, pueden ver el avance, darse cuenta a tiempo si se está perdiendo el rumbo, responder preguntas rápidamente y priorizar requerimientos • Énfasis en adaptación al cambio vs planeamiento • Se espera el cambio, no se reacciona ante él. El diseño, la especificación, el control de cambios y el código se hacen pensando en el cambio. • Se utiliza el refactoring para ir adaptando el código a medida que se hacen los cambios • Énfasis en simplicidad vs complejidad • Se busca simplicidad. Algo simple es más fácil de entender y, sobretodo, de modificar. • Parte del proceso incluye activamente modificar o remover código complejo y reemplazarlo por código más simple

50. Modelos Ágiles • VentajasDe acuerdo al método ágil a utilizar hay distintas ventajas o desventajas, pero pueden ser resumidas en: • Adaptación al cambio asumida • Se aprovecha el potencial de todo el equipo • Mayor visibilidad a los clientes