1.
ALUMNOS: JOSÉ HILARIO GOMEZ AMERICA JUÁREZ GONZÁLEZ SERGIO DURON MACÍAS. VANESSA VILLALPANDO SERNA

2.
LAS MÉTRICAS

3.
¿QUÉ SON LAS MÉTRICAS? <ul><li>Las métricas son una metodología de planificación, desarrollo y mantenimiento de sistemas de información. Las métricas son una pieza fundamental en el proceso de desarrollo de software. Con ella vamos a poder tener datos objetivos de eficacia, eficiencia y calidad. Las métricas ayudan al gestor de un proyecto a conducirlo al éxito y al responsable de un servicio a controlarlo con argumentos objetivos cuantificados. Igualmente estas métricas servirán para la detección de los riesgos operacionales y para la generación de eventos que ayuden a la operación en el día a día de los servicios. </li></ul>

4.
¿QUÉ SON LAS MÉTRICAS DE SOFTWARE? <ul><li>La aplicación continua de mediciones basadas en técnicas para el proceso de desarrollo del software y sus productos para suministrar información relevante a tiempo, así el administrador junto con el empleo de estas técnicas mejorará el proceso y sus productos. Las métricas de software proveen la información necesaria para la toma de decisiones técnicas. </li></ul>

5.
<ul><li>Las métricas son la maduración de una disciplina, que, van a ayudar a la evaluación de los modelos de análisis y de diseño, en donde proporcionarán una indicación de la complejidad de diseños procedimentales y de código fuente, y ayudaran en el diseño de pruebas más efectivas; Es por eso que propone un proceso de medición, el cual se puede caracterizar por cinco actividades: </li></ul><ul><li>(1) Formulación : La obtención de medidas y métricas del software apropiadas para la representación de software en cuestión. </li></ul><ul><li>(2) Colección : El mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas. </li></ul><ul><li>(3) Análisis : El cálculo de las métricas y la aplicación de herramientas matemáticas. </li></ul><ul><li>(4) Interpretación : La evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la representación. </li></ul><ul><li>(5) Realimentación : Recomendaciones obtenidas de la interpretación de métricas técnicas trasmitidas al equipo de software. </li></ul>

6.
<ul><li>Se conoce que no existe un cuerpo de principios en conjunto, puedan dirigir al desarrollo de métricas de software a que sean independientes del lenguaje, a ambientes y a metodologías de programación. Matemáticamente, estos principios son teorías e implementaciones críticas ya que una métrica, tiene ciertas propiedades matemáticas y atributos de ingeniería, así como también ciertas realimentaciones de productividad. Es por eso que alcanzamos a responder preguntas fundamentales deseadas de una métrica. </li></ul><ul><li>Las métricas de software incluyen otras varias actividades, tales como: </li></ul><ul><li>- Estimación de costo y el esfuerzo </li></ul><ul><li>- Medición de la productividad </li></ul><ul><li>- Acumulación de datos </li></ul><ul><li>- Realización de modelos y mediciones de la calidad </li></ul><ul><li>- Elaboración de modelos de seguridad </li></ul><ul><li>- Evaluación y modelos de desempeño </li></ul><ul><li>- Valoración de las capacidades y de la madurez </li></ul><ul><li>- Administración por métricas </li></ul><ul><li>- Evaluación del método y herramientas </li></ul>

7.
USOS DE LAS MÉTRICAS EN LA INGENIERÍA DEL SOFTWARE

8.
PARA QUE UTILIZARLAS… <ul><li>Una métrica es una medida efectuada sobre algún aspecto del sistema en desarrollo o del proceso empleado que permite, previa comparación con unos valores (medidas) de referencia, obtener conclusiones sobre el aspecto medido con el fin de adoptar las decisiones necesarias. </li></ul><ul><li>Con esta definición, la definición y aplicación de una métrica no es un objetivo en sí mismo sino un medio para controlar el desarrollo de un sistema de software. </li></ul>

9.
<ul><li>Para saber que usos o utilidades nos pueden brindar las métricas puede o deber ser necesario saber con que tipo de métricas estamos tratando, ya sea : </li></ul><ul><ul><ul><li>sobre el producto, ó </li></ul></ul></ul><ul><ul><ul><li>sobre el proceso. </li></ul></ul></ul>

10.
MÉTRICA SOBRE EL PRODUCTO <ul><li>Las métricas sobre el producto están orientadas a estimar las características del mismo antes de su desarrollo. Estas estimaciones se basan en el conocimiento que los desarrolladores adquieren a partir de datos obtenidos de proyectos anteriores. </li></ul><ul><li>Se basan en tres puntos o aspectos: </li></ul><ul><ul><li>Tamaño estimado del código </li></ul></ul><ul><ul><li>Complejidad estimada </li></ul></ul><ul><ul><li>Robustez </li></ul></ul>

11.
TAMAÑO ESTIMADO DEL CÓDIGO <ul><li>La forma más obvia y la que se ha utilizado históricamente para estimar el tamaño es contar el número de líneas de código. Con ciertas normas para determinar qué es lo que se cuenta (líneas de comentario, código incluido, etc.) y siempre referido a un lenguaje concreto, lo que los valores nos dan es un valor para poder estimar el esfuerzo necesario en futuros desarrollos. </li></ul><ul><li>Ha sido muy criticada la tendencia en estimar el esfuerzo en base a las líneas de código. Una de las críticas se centra en que la complejidad del desarrollo no está directamente ligada al tamaño cuando nos movemos hacia el dominio de los sistemas concurrentes, distribuidos o de tiempo real. En ellos, las medidas deben referirse a estimaciones del mismo tipo de productos. </li></ul>

12.
COMPLEJIDAD ESTIMADA . <ul><li>Surge con el fin de superar el problema de estimados de tamaño del código, y para ello se utiliza un método llamado puntos de función que se basa en el empleo de factores normalizados para juzgar la importancia relativa de varios requisitos funcionales. </li></ul><ul><li>Parte de cinco funciones básicas que suelen aparecer en muchos sistemas: </li></ul><ul><ul><li>Entradas: Pantallas o formatos empleados para introducir datos a un programa. </li></ul></ul><ul><ul><li>Salidas: Pantallas o informes empleados para utilizarlos con otros programas o para lectura directa . </li></ul></ul><ul><ul><li>Consultas: Mecanismos para pedir ayuda o dar órdenes de ejecución. </li></ul></ul><ul><ul><li>Ficheros de datos: Conjuntos lógicos de información empleados por una aplicación (ya sean tablas en memoria como ficheros de disco) junto con los procedimientos de acceso a los mismos. </li></ul></ul><ul><ul><li>Interfaces: Ficheros compartidos con otras aplicaciones. </li></ul></ul><ul><ul><li>La idea básica del método consiste en definir unas estimaciones de complejidad para cada una de estas funciones (en forma de pesos relativos) y estimar, dadas las especificaciones del sistema, cuántos elementos de cada tipo van a ser necesarios. </li></ul></ul>

13.
ROBUSTEZ <ul><li>Por robustez de un programa se entiende la ausencia de fallos en su ejecución con diferentes datos de entrada durante intervalos de tiempo predeterminados. </li></ul><ul><li>La robustez de un programa está ligada a la aparición de problemas durante su ejecución. Generalmente, el número de fallos encontrados durante la fase de prueba y, posteriormente, durante el mantenimiento del sistema constituye una medida de la calidad del producto de software e indirectamente, de la calidad del proceso de desarrollo. </li></ul><ul><li>La importancia de conocer el número de fallos encontrados en un intervalo de tiempo no reside únicamente en obtener un valor global de la calidad del producto sino en los beneficios derivados de su análisis. </li></ul><ul><li>Las medidas estadísticas de fiabilidad (tiempo medio entre fallos encontrados durante la ejecución, reducción del número de recopilaciones necesarias, etc.) sirven para alimentar el proceso de desarrollo. </li></ul>

14.
MÉTRICAS SOBRE EL PROCESO <ul><li>Existen otros tipos de datos que se pueden tomar durante el desarrollo de un producto de software y que no están ligados al producto sino a los procesos implicados. El análisis de cómo estos procesos se realizan a partir de medidas tomadas en el desarrollo es la base para su posterior mejora. </li></ul><ul><li>Algunos de los elementos a medir son: </li></ul><ul><ul><li>Distribución del esfuerzo en cada una de las fases con objeto de poder estimar los recursos necesarios. Obsérvese que esta medida es complementaria a las de tamaño mencionadas anteriormente; aquella nos permitía conocer los recursos globales necesarios; de lo que se trata aquí es de obtener medidas reales y extrapolarlas a futuros proyectos. </li></ul></ul><ul><ul><li>Productividad medida en número de líneas de código documentadas que es capaz de producir una persona en una unidad de tiempo. Podemos decir que los valores típicos de productividad por persona (empleando tecnologías de desarrollo convencional) están entre 30 y 50 líneas de código por día de trabajo. </li></ul></ul>

15.
CLASIFICACIÓN DE LAS MÉTRICAS

16.
MÉTRICAS SOBRE EL PROCESO <ul><li>Las métricas del software responden a dos </li></ul><ul><li>objetivos: valorar y estimar . </li></ul><ul><li>Las magnitudes objeto de valoración son </li></ul><ul><li>tres: la calidad , fiabilidad y productividad . </li></ul><ul><li>La estimación parte de mediciones para </li></ul><ul><li>prever el esfuerzo y el tiempo que debe </li></ul><ul><li>invertirse en un proyecto dado, y las </li></ul><ul><li>características del resultado final. </li></ul>

17.
SEGÚN LOS CRITERIOS <ul><li>De complejidad: </li></ul><ul><li>Métricas que definen la medición de la complejidad: volumen, tamaño, anidaciones , y configuración </li></ul><ul><li>El tamaño es una medida empleada fundamentalmente por tres razones: es fácil de obtener una vez que el programa ha sido completado, es uno de los factores más importantes en los métodos de desarrollo, y la productividad se expresa mediante el tamaño del código (KLDC) </li></ul>

18.
DE CALIDAD: <ul><li>Métricas que definen la calidad del software: exactitud, estructuración o modularidad, pruebas, mantenimiento. </li></ul><ul><li>La estructura lógica de un programa es el mecanismo que le permite realizar las distintas funciones para las que fue construido. </li></ul><ul><li>La estructura de un algoritmo se representa perfectamente con las gráficas denominadas diagramas de flujo. </li></ul>

19.
<ul><li>De competencia: </li></ul><ul><li>Métricas que intentan valorar o medir las actividades de productividad de los programadores con respecto a su certeza, rapidez, eficiencia y competencia. </li></ul><ul><li>A la hora de valorar un sistema software debe considerarse la cantidad de esfuerzo que debe invertir el equipo de desarrollo para culminar su construcción. El coste del desarrollo es prácticamente el del trabajo empleado, pues la parte asignada a materiales es de tan poca entidad que resulta despreciable frente a la mano de obra. </li></ul>

20.
DE DESEMPEÑO: <ul><li>Métricas que miden la conducta de módulos y sistemas de un software, bajo la supervisión del SO o hardware. </li></ul><ul><li>El grado de modularidad afecta a la calidad del diseño. Es preferible un exceso a un defecto de modularidad, pues en este último caso contendrá más errores. La cuantificación de la modularidad se obtiene midiendo la cantidad de elementos del gráfico. </li></ul>

21.
ESTILIZADAS: <ul><li>Métricas de experimentación y de preferencia: estilo de código, convenciones, limitaciones, etc. </li></ul><ul><li>Entre las diversas ventajas de las técnicas de diseño se pueden destacar las siguientes: </li></ul><ul><li>1.- Comprensibilidad : programadores y usuarios pueden comprender fácilmente la lógica del programa. </li></ul><ul><li>2.- Manejabilidad : los gestores pueden asignar fácilmente personal y recursos a los distintos módulos representados por tareas. </li></ul><ul><li>3.- Eficiencia : el esfuerzo de implementación puede reducirse. </li></ul><ul><li>4.- Reducción de errores : los planes de prueba se simplifican notablemente. </li></ul><ul><li>5.-Reducción del esfuerzo de mantenimiento : la división en módulos favorece que las distintas funciones las lleven a cabo módulos diferenciados. </li></ul>

22.
SEGÚN EL CONTEXTO EN QUE SE APLICAN <ul><li>Métricas de proceso: </li></ul><ul><li>Se recopilan de todos los proyectos, durante un largo periodo de tiempo </li></ul><ul><li>Caracterizados por: </li></ul><ul><li>‣ Control y ejecución del proyecto. </li></ul><ul><li>‣ Medición de tiempos de las fases. </li></ul>

23.
MÉTRICAS DE PROYECTO: <ul><li>Permiten evaluar el estado del proyecto. </li></ul><ul><li>Permiten seguir la pista de los riesgos. </li></ul>

24.
MÉTRICAS DE PRODUCTO: <ul><li>Se centran en las características del software y no en como fue producido. </li></ul><ul><li>También son productos los artefactos, </li></ul><ul><li>documentos, modelos, y componentes que </li></ul><ul><li>conforman el software. </li></ul><ul><li>Se miden cosas como el tamaño, la calidad, totalidad, la volatilidad, y el esfuerzo. </li></ul>