CAPÍTULO 2. Empezaremos por definir los posibles términos que se encuentran. encerrados en la palabra métrica, porque es muy común asociarla con las

Documentos relacionados
Ingeniería del Software Ingeniería del Software de Gestión. Tema 3 Metodologías de Desarrollo de Software

Objetivos. Plan. Cambios de grupos Prof. sustituto: Alicia Villanueva

Grado en que el producto software satisface las necesidades expresadas o implícitas, cuando se usa bajo condiciones determinadas. ISO

PLANIFICACIÓN, PROGRAMACIÓN Y COSTOS DE MANTENIMIENTO

Requerimientos de Software

CRITERIOS DE ACREDITACIÓN. Programas de Computación Ciclo de Acreditación 2016

ESTÁNDAR INTERNACIONAL DE OTROS SERVICIOS DE ASEGURAMIENTO

Medición y estimación del software. Técnicas y métodos para mejorar la calidad y la productividad

OFS Órgano de Fiscalización Superior

Ingeniería de Requerimientos. requiere de un Sistema de Software.

La gestión por procesos

PRUEBAS DE USABILIDAD PRUEBAS DE USABILIDAD

Grado en Ingeniería Informática. Plan de proyecto. Desarrollo de Sistemas de Información Corporativos. Departamento de Informática

Selección del Hardware y Software Administración del proceso de desarrollo de Sistemas de Información.

Ley o normas que regulan las competencias y recursos asignados a la institución.

Elaborar y documentar el Plan de trabajo anual que la Unidad de Auditoría Interna desarrollará durante un período fiscal.

Examinar y tomar acciones sobre los problemas operativos Reducir gastos y aumentar la eficiencia operativa.

libreriadelagestion.com

TEMA 7: INGENIERIA DEL SOFTWARE.

El Proceso. Capítulo 2 Roger Pressman, 5 a Edición. El Proceso de Desarrollo de Software

SISTEMA DE ADMINISTRACION DE RIESGO OPERATIVO

5. Cuáles son las actividades primarias de la producción de software

EL PAPEL DE LA ESTADISTICA EN O Y M. Objetivo: Identificar índices estadísticos, y métodos más convenientes, para aplicarlos en el estudio de O y M.

Instrumentos de Control de Gestión en el Presupuesto. Indicadores de Desempeño.

Dar una introducción sobre la asignatura IO Familiarizar al estudiante con las características y aplicación del modelo de matriz de decisiones

9.3 GLOSARIO DE TÉRMINOS

INDICADORES DE GESTIÓN

TEMA Nº Desarrollo curricular. 2. Elaboración del currículum EL MODELO DE CARTAS DESCRIPTIVAS A. DEFINICIONES

Contenidos Mínimos del Estudio de Factibilidad de un Proyecto de Inversión Pública en fase de preinversión

ESTRUCTURACION DEL PROGRAMA DE ASIGNATURA 1. INFORMACION GENERAL

PROJECT MANAGEMENT OFFICE

Metodología para la solución de problemas programables

COBIT 4.1. Planear y Organizar PO10 Administrar Proyectos. By Juan Antonio Vásquez

DIPLOMADO. Evaluación de la Calidad de la práctica docente para la implementación del Nuevo Modelo Educativo en Escuelas de Ingeniería del I.P.N.

El Software. Francisco Ruiz González. Escuela Superior de Informática Ciudad Real Universidad de Castilla-La Mancha.

SILABO DE LA ASIGNATURA INGENIERIA DEL SOFTWARE

Universidad Centroccidental Lisandro Alvarado. Decanato de Ciencias y Tecnología Departamento de Sistemas

CAPITULO V CONCLUSIONES Y RECOMENDACIONES. Índice Verificación de hipótesis Conclusiones Recomendaciones.

Diplomado Administración de la Construcción

Estimación para Proyectos Software

PLANIFICACION DE UN PROYECTO DE SOFTWARE

OBJETIVO DE PRODUCTO OBJETIVO DE EQUIPO

Documento Técnico NIA-ES CNyP y Dpto. Técnico

TEMA 1: SISTEMAS MODELADOS POR ECUACIONES DIFERENCIALES EN INGENIERÍA QUÍMICA. CLASIFICACIÓN. GENERALIDADES.

MSc. ROSALIA RUIZ DE CIPRIANI/Marian l.

Metodología de la Investigación

5. Los objetivos de la Calidad de los Datos (OCD) y la Evaluación de la

Líneas de Responsabilidad y Funciones. para la Estructura de Puestos de Caja Rural de Teruel

CURSO DE INTELIGENCIA DE FUENTES ABIERTAS

Resultados del Estudiante 1. Diseño en Ingeniería

PANADERIA. Taller de Analisis y Diseño de Sistemas. Orientador:

Presencia X A distancia Teleformación Horas tut. presenciales Horas tut. a distancia 68 Horas totales 68

Dependencia/ secretaría. Secretaria General y Administrativa INTRODUCCIÓN

MODELO IBEROAMERICANO DE EXCELENCIA EN LA GESTION

Dr. César Castañeda Vázquez del Mercado. PRESENTACIÓN 1ª ETAPA Fondo Sectorial SECTUR-CONACYT Ciudad de México, México Febrero de 2013

Descripción del Curso

Tipos y análisis de estudios empíricos.

UNIVERSIDAD AUTÓNOMA DE CHIAPAS FACULTAD DE INGENIERÍA CAMPUS I TOPOGRAFÍA GENERAL Y PRÁCTICAS

CARRERA DE INGENIERÍA CIVIL EN INFORMÁTICA COMPETENCIAS ESPECÍFICAS Y SUS NIVELES DE DOMINIO

GESTIÓN POR PROCESOS Y MEJORA CONTINUA

CAPÍTULO 7. El motivo de la realización del tutorial métricas de software fue para

INVESTIGACIÓN EVALUATIVA. Elena Ramos Cristina Alonso Noelia Moyano Esmeralda Olmo Natalia Gómez

PROGRAMA DEL CURSO GERENCIA DE LA EJECUCIÓN DE PROYECTOS DE INVERSIÓN

Rol de las Oficinas de Proyecto (PMO) en las Organizaciones. Qué es lo que hay dentro de una PMO?

M. C. Felipe Santiago Espinosa

Coordinación de Servicios Informáticos (CSEI)

Algoritmos y solución de problemas. Fundamentos de Programación Otoño 2008 Mtro. Luis Eduardo Pérez Bernal

PROGRAMA DE CAPACITACIÓN PARA LA CAPTURA, PROCESAMIENTO Y CODIFICACIÓN DEL SISTEMA DE CLASIFICACIÓN GRUPOS RELACIONADOS CON EL DIAGNÓSTICO (IR-GRD)

Nombre de la asignatura: Algoritmos y Lenguajes de programación.

1. Computadores y programación

Por qué conformarse con ser bueno si se puede ser mejor

PROCESOS DE LA DIRECCIÓN DE PROYECTO I N G. C R U C E S H E R N A N D E Z G U E R R A U N I V E R S I D A D A L A S P E R U A N A S

Indicadores de Gestión para la Acreditación Universitaria

La ley y las competencias profesionales en atletismo.

Diplomatura OHSAS 18001: Módulo 9/ Sesión única (C4)

INTERPRETACIÓN NORMA OHSAS 18001:2007 MÓDULO 1 SESIÓN 1 INTERPRETACIÓN DE LA NORMA OHSAS 18001:2007 DOCENTE: Ing. Dª. Ana I.

6.5 ESTIMAR LA DURACIÓN DE LAS ACTIVIDADES

CAPITULO IV LA CALIDAD Y LAS PYMES

Curso Microsoft SharePoint Server 2010 Designing and Developing Applications (10232)

CONTABILIDAD - ADMINISTRADORES - INTERNO - PERSONAL OPERATIVO - TRABAJADORES - ACREEDORES - ESTADO

CUARTA UNIDAD: FORMULACIÓN DEL PLAN DE AUDITORÍA AMBIENTAL. CONTENIDO DEL PLAN DE AUDITORÍA AMBIENTAL

Cómo Establecer Puntos de Corte o Selección para Estandares? Que es un Estandard?

Versión: 01. Fecha: 01/04/2013. Código: F004-P006-GFPI GUÍA DE APRENDIZAJE Nº 1. IDENTIFICACIÓN DE LA GUIA DE APRENDIZAJE. Programa de Formación:

SECCIÓN DE SUMINISTROS Y ALMACENAMIENTO

DIPLOMADO EN SISTEMAS DE GESTIÓN EN SEGURIDAD Y SALUD OCUPACIONAL OHSAS 18001

Capítulo III: MARCO METODOLÓGICO

Introducción de la aplicación de programación LEGO MINDSTORMS Education EV3

En esta sección: Guía CENEVAL EGEL-IINDU 2017 Resuelta Nueva Generación. 1.- Ficha técnica del producto. 2.- Contenido temático del producto.

Cómo estudiar más y mejor? Autoras: MsC. Haydee Leal García. MsC. Sol Angel Galdós Sotolongo. Investigadoras del ICCP

LIDERAZGO PARA MANDOS MEDIOS: PROGRAMA MODULAR DE CAPACITACIÓN

Propuesta de currículo para Ingeniería en Computación

UNA HERRAMIENTA PARA LA GESTION DE COSTOS. Luis Vaca Guevara

Presencia A distancia X Teleformación

UNIDAD 1: CONCEPTOS BA SICOS DE BASE DE DATOS

Gestión de la Calidad y Sistemas Integrados

Conceptos básicos de bases de datos

SISTEMAS DE INFORMACIÓN PARA LA GESTIÓN DE LA EMPRESA

Administrar una organización a través de resultados financieros, es igual que conducir un automóvil viendo siempre por el retrovisor Administrar con

TEMA 2 Introducción a C# ANÁLISIS Y DESARROLLO DE APLICACIONES INFORMÁTICAS Curso 2010/2011

BASES DE DATOS TEMA 2 MODELOS DE DATOS

Transcripción:

Conceptos básicos de Métricas CAPÍTULO 2 Empezaremos por definir los posibles términos que se encuentran encerrados en la palabra métrica, porque es muy común asociarla con las palabras medición y medida, aunque estas tres son distintas. La medición es el proceso por el cual los números o símbolos son asignados a atributos o entidades en el mundo real tal como son descritos de acuerdo a reglas claramente definidas [Fenton 91]. Una medida proporciona una indicación cuantitativa de extensión, cantidad, dimensiones, capacidad y tamaño de algunos atributos de un proceso o producto [Pressman 98]. El IEEE Standard Glosary of Software Engering Terms define como métrica como una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado [Len O. Ejiogo 91]. Muchos investigadores han intentado desarrollar una sola métrica que proporcione una medida completa de la complejidad del software. Aunque se han propuesto docenas de métricas o medidas, cada una de éstas tienen un punto de vista diferente; y por otro lado, aunque bien se sabe que existe la necesidad de medir y controlar la complejidad del software, es difícil de obtener un solo valor de estas métricas de calidad. Aun así debería ser posible desarrollar medidas de diferentes atributos internos del programa. 6

Aunque todos estos obstáculos son motivo de preocupación, no son motivo de desprecio hacia las métricas. Es por eso que se dice que la medición es esencial, si es que se desea realmente conseguir la calidad en software. Es por eso que existen distintos tipos de métricas para poder evaluar, mejorar y clasificar al software final, en donde serán manejadas dependiendo del entorno de desarrollo del software al cual pretendan orientarse. 2.1 Qué son las métricas de software? Michael [ 99] define las métricas de software como 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 estás 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. En la figura 2.1 se ilustra una extensión de esta definición para incluir los servicios relacionados al software como la respuesta a los resultados del cliente: Mediciones Basadas en técnicas Figura 2.1 Servicios Relacionados al Software [Michael M. 99] aplicar Procesos, Productos y Servicios mejora r proveer Ingeniería y Administración de la Información 7

Las métricas son la maduración de una disciplina, que, según Pressman [ 98] van a ayudar a la (1) evaluación de los modelos de análisis y de diseño, (2) en donde proporcionarán una indicación de la complejidad de diseños procedimentales y de código fuente, y (3) 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: (1) Formulación: La obtención de medidas y métricas del software apropiadas para la representación de software en cuestión. (2) Colección: El mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas. (3) Análisis: El cálculo de las métricas y la aplicación de herramientas matemáticas. (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. (5) Realimentación: Recomendaciones obtenidas de la interpretación de métricas técnicas trasmitidas al equipo de software. 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 8

realimentaciones de productividad. Es por eso que alcanzamos a responder tres preguntas fundamentales deseadas de una métrica [Fenton 91]. Cuánto mide? - la complejidad en la medida Qué tan bien mide? - la calidad en la medida Qué tanto tiempo mide? - la predicción Las métricas de software incluyen otras varias actividades, tales como: - Estimación de costo y el esfuerzo - Medición de la productividad - Acumulación de datos - Realización de modelos y mediciones de la calidad - Elaboración de modelos de seguridad - Evaluación y modelos de desempeño - Valoración de las capacidades y de la madurez - Administración por métricas - Evaluación del método y herramientas 2.2 Clasificación de Métricas La clasificación de una métrica de software refleja o describe la conducta del software. A continuación se muestra una breve clasificación de métricas de software, descritas por Lem O. Ejiogu [ 91]: 9

Métricas de complejidad: Son todas las métricas de software que definen de una u otra forma la medición de la complejidad; Tales como volumen, tamaño, anidaciones, costo (estimación), agregación, configuración, y flujo. Estas son los puntos críticos de la concepción, viabilidad, análisis, y diseño de software. Métricas de calidad: Son todas las métricas de software que definen de una u otra forma la calidad del software; Tales como exactitud, estructuración o modularidad, pruebas, mantenimiento, reusabilidad, cohesión del módulo, acoplamiento del módulo, etc. Estas son los puntos críticos en el diseño, codificación, pruebas y mantenimiento. Métricas de competencia: Son todas las métricas que intentan valorar o medir las actividades de productividad de los programadores o practicantes con respecto a su certeza, rapidez, eficiencia y competencia. No se ha alcanzado mucho en esta área, a pesar de la intensa investigación académica. Métricas de desempeño: Corresponden a las métricas que miden la conducta de módulos y sistemas de un software, bajo la supervisión del sistema operativo o hardware. Generalmente tienen que ver con la eficiencia de ejecución, tiempo, almacenamiento, complejidad de algoritmos computacionales, etc. Métricas estilizadas: Son las métricas de experimentación y de preferencia; Por ejemplo: estilo de código, identación, las convenciones denominando de datos, las 10

limitaciones, etc. Pero estas no se deben confundir con las métricas de calidad o complejidad. Variedad de métricas: tales como portabilidad, facilidad de localización, consistencia. Existen pocas investigaciones dentro del área. Estas clasificaciones de métricas fortalecen la idea, de que más de una métrica puede ser deseable para valorar la complejidad y la calidad del software. 2.3 Diferentes enfoques de métricas Se han propuesto cientos de métricas para el software, pero no todas proporcionan suficiente soporte práctico para su desarrollo. Algunas demandan mediciones que son demasiado complejas, otras son tan esotéricas que pocos profesionales tienen la esperanza de entenderlas, y otras violan las nociones básicas intuitivas de lo que realmente es el software de alta calidad. Es por eso que se han definido una serie de atributos que deben acompañar a las métricas efectivas de software, por lo tanto la métrica obtenida y las medidas que conducen a ello deben cumplir con las siguientes características fundamentales: - Simple y fácil de calcular: debería ser relativamente fácil de aprender a obtener la métrica y su cálculo no obligara a un esfuerzo o a una cantidad de tiempo inusuales. 11

- Empírica e intuitivamente persuasiva: la métrica debería satisfacer las nociones intuitivas del ingeniero de software sobre el atributo del producto en cuestión (por ejemplo: una métrica que mide la cohesión de un módulo debería aumentar su valor a medida que crece el nivel de cohesión). - Consistente en el empleo de unidades y tamaños: el cálculo matemático de la métrica debería utilizar medidas que no lleven a extrañas combinaciones de unidades. Por ejemplo, multiplicando el número de personas de un equipo por las variables del lenguaje de programación en el programa resulta una sospechosa mezcla de unidades que no son intuitivamente concluyentes. - Independiente del lenguaje de programación: las métricas deberían apoyarse en el modelo de análisis, modelo de diseño o en la propia estructura del programa. No deberían depender de los caprichos de la sintaxis o semántica del lenguaje de programación. - Un mecanismo eficaz para la realimentación de calidad: la métrica debería suministrar al desarrollador de software información que le lleve a un producto final de superior calidad. No obstante que la mayoría de las métricas de software compensan las características anteriores, algunas de las métricas usualmente empleadas no cumplen una o dos características. Un ejemplo es el punto funcional (PF, tratado en la sección 3.5), en donde se consigue argumentar que el atributo es 12

consistente y objetivo pero falla por que un equipo ajeno independiente puede no ser capaz de conseguir el mismo valor de PF que otro equipo que emplee la misma información del software. En tal caso la siguiente pregunta se manifiesta, Debería entonces rechazar la medida PF?. La respuesta es por supuesto que No!., la PF aporta una visión interna útil y por lo tanto provee de un valor claro, incluso si no satisface un atributo perfectamente. Este es un ejemplo en donde el uso de las métricas dependen de los factores individuales del desarrollador o desarrolladores del software. 2.4 Las métricas en el proceso y dominio del proyecto Las métricas de proceso de software se emplean para fines estratégicos, y las métricas del proyecto de software son tácticas, éstas últimas van a permitir proporcionar al desarrollador de proyectos del software una evaluación al proyecto que sigue en continuo desarrollo, equivalentemente podrá ver los defectos que logren provocar riesgos a largo plazo (áreas problema); y observar si el área de trabajo (equipo) y las distintas tareas se ajustarán. Existe una preocupación en la unificación de las métricas dentro del proceso del software, dado que los desarrolladores mexicanos de software no tienen la cultura de la medición. Es por eso que el uso de métricas demanda un cambio cultural, tanto en el recopilado de datos (investigación histórica), como en el cálculo de métricas (LDC, PF, métricas de calidad y orientadas a objetos) y asimismo en la evaluación (resultados obtenido), para poder comenzar un 13

programa de bases de métricas y justamente obtener una guía, asimismo una base de datos tanto de los procesos como de los productos y de este modo adquirir una visión más profunda de lo que se está elaborando. Las métricas de software nos aportan una manera de estimar la calidad de los atributos internos del producto, permitiendo así al ingeniero de software valorar la calidad antes de construir el producto, así el tiempo invertido será identificando, examinando y administrando el riesgo, este esfuerzo merece la pena por muchas razones ya que habrá disminución de disturbios durante el proyecto, asimismo se podrá desarrollar una habilidad de seguir y controlar el proyecto y se alcanzará la seguridad que da planificar los problemas antes de que ocurran, además conseguiremos absorber una cantidad significativa del esfuerzo en la planificación del proyecto. Del mismo modo existen diferentes tipos de métricas para poder evaluar, mejorar y clasificar al software desde sus inicios hasta el producto final, de las cuales se verán en los siguientes capítulos. 14