2. Métricas del Producto



Documentos relacionados
CALIDAD DEL SOFTWARE TESTS DE EXAMEN ACTUALIZADO SEP TEMA 8 MÉTRICAS DEL SOFTWARE

CLASE # 5 TÉCNICAS DE CAJA BLANCA

Técnicas de prueba 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE

Fundamentos del diseño 3ª edición (2002)

Diseño orientado al flujo de datos

EL PROCESO DE DISEÑO DEL SOFTWARE

Métricas. Valentin Laime. Calidad de Software

DISEÑO DE FUNCIONES (TRATAMIENTOS)

MÉTRICAS DE SOFTWARE. Presentado por: Jhon Alexander Guamanga Cyntia Mileidy Herrera Andrés Felipe Orejuela

Proceso de desarrollo del software modelo en cascada

TEMA 3. EL PROCESO DE COMPILACIÓN, DEL CÓDIGO FUENTE AL CÓDIGO MÁQUINA

Entidad Formadora: Plan Local De Formación Convocatoria 2010

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

GENERACIÓN DE CÓDIGO

1. Descripción y objetivos

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 9: CRITERIOS DE CALIDAD DE DISEÑO MODULAR

Soporte y mantenimiento. Generalidades

Gestion de archivos. Problemas al almacenar datos sólo en la memoria:

6.3 CASOS DE PRUEBA CAJA BLANCA

GRAFOS. Prof. Ing. M.Sc. Fulbia Torres

INGRID Gestión geográfica de activos urbanos y mantenimiento

Soporte y mantenimiento. Generalidades

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

ANÁLISIS SEMÁNTICO. Especificación formal: Semántica Operacional, semántica denotacional, semántica Axiomática, Gramáticas con Atributos.

Medidas de la complejidad del software.

Arquitectura de Aplicaciones

Tema 2 Conceptos básicos de programación. Fundamentos de Informática

Ingeniería de Software. Pruebas

UNIDADES DE ALMACENAMIENTO DE DATOS

Software Computacional y su clasificación

Introducción. Conceptos y principios. Introducción. Introducción. Elementos del modelo de análisis. Elementos del modelo de diseño.

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 7: VALIDACIÓN

Unidad II: Análisis de Redes

TEMA 12: CUALIDADES DE UN BUEN DISEÑO

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, Introducción al Diseño de Software

Introduccion al Lenguaje C. Omar Andrés Zapata Mesa Grupo de Fenomenología de Interacciones Fundamentales, (Gfif) Universidad de Antioquia

Elementos requeridos para crearlos (ejemplo: el compilador)

Hoy terminamos caja blanca

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE

Geolocalización de Sitios de Interés Para Aplicaciones Móviles G-SIAM. Plan de Aseguramiento de Calidad del Software SQAP

Área Académica: Licenciatura Sistemas Computacionales. Profesor: Lic. Virginia Arguelles Pascual

Análisis de redes PERT-CPM

INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones

Decisión: Indican puntos en que se toman decisiones: sí o no, o se verifica una actividad del flujo grama.

LA LOGÍSTICA COMO FUENTE DE VENTAJAS COMPETITIVAS

Resolución de Problemas

Ingeniería de Software Avanzada

Autenticación Centralizada

Patrones para persistencia (I) Ingeniería del Software II


Capítulo 4. Prueba de Adaptabilidad

Análisis de Sistemas. M.Sc. Lic. Aidee Vargas C. C. octubre 2007

Fundamentos de la Programación

Administración de proyectos. Organizar, planificar y programar los proyectos de software

El Software. Es lo que se conoce como el ciclo de vida del software.

Es de aplicación a todas aquellas situaciones en las que se necesita desplegar un objetivo para obtener una visión clara de cómo debe ser alcanzado.

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A.

TECNÓLOGO EN INFORMÁTICA PLAN DE ESTUDIOS

Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software

Proyecto MONO. Juantomás García. 1. Introducción. GNOME Hispano

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

EL MODELO DE ESTRATIFICACIÓN POR CAPAS DE TCP/IP DE INTERNET

CALIDAD DEL SOFTWARE TESTS DE EXAMEN ACTUALIZADO SEP TEMA 4 MODELOS, METODOLOGÍAS Y ESTÁNDARES: ESTRATEGIAS PARA ALCANZAR LA CALIDAD

Máxima flexibilidad en paletizado automático al mejor precio

Capítulo 4. Vectores y matrices. 4.1 Declaración de tablas. 4.2 Declaración estática de tablas

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

Calidad Escuela de Ingeniería de Sistemas y Computación Desarrol o de Software II Agosto Diciembre 2007

TELECOMUNICACIONES Y REDES

implantación Fig. 1. Ciclo de vida tradicional

TEMA 2 Componentes y estructura de una red de telecomunicación.

Almacenamiento virtual de sitios web HOSTS VIRTUALES

TRABAJO PRACTICO No 7. MEDICION de DISTORSION EN AMPLIFICADORES DE AUDIO ANALIZADORES DE ESPECTRO DE AUDIO

Tema 3 Metodologías de Desarrollo de Software

Presentamos ONYX Servicios Profesionales

2002 Emerson Process Management. Todos los derechos reservados. Vea este y otros cursos en línea en

Figura 4.1 Clasificación de los lenguajes de bases de datos

80294 Microsoft Dynamics CRM 2011 Customization and Configuration

CMMI (Capability Maturity Model Integrated)

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases

Arquitectura de sistema de alta disponibilidad

PATRONES. Experto. Solución:

DISEÑO DE COMPONENTES DE SOFTWARE *

INSTALACIÓN, OPERACIÓN Y PROGRAMACIÓN DE EQUIPOS Y SISTEMAS TELEFÓNICOS

Entre los más conocidos editores con interfaz de desarrollo tenemos:

Árboles. Cursos Propedéuticos Dr. René Cumplido M. en C. Luis Rodríguez Flores

Topologías. Principios de comunicaciones de datos

PROCEDIMIENTO OPERATIVO DESARROLLAR SISTEMAS INFORMÁTICOS PDO-COCTI-DTIN-04

Ingeniería en Informática

Introducción a la Programación 11 O. Humberto Cervantes Maceda

GUIA PROGRAMACIÓN ORIENTADA A OBJETOS

1.1. Introducción y conceptos básicos

ANEXO TRES INSTRUCTIVO PARA EL LLENADO DE LA FICHA TÉCNICA DEL INDICADOR

Capitulo III. Diseño del Sistema.

Interoperabilidad de Fieldbus

Práctica 5. Curso

Metodología Orientada a Objetos Clave Maestría en Sistemas Computacionales

UNIVERSIDAD DE SEVILLA PRÁCTICAS DE LABORATORIO ANÁLISIS SINTÁCTICO (1) LENGUAJES FORMALES Y AUTÓMATAS CURSO 2006/2007

#SoftwareLibre13 Reutiliza tu Antiguo PC con Linux

Programación Orientada a Objetos en Java

Transcripción:

Medición 52 Programa 1. Medición ió y experimentación ió en Ingeniería del Software Introducción Teoría representacional de la medición. Experimentación en Ingeniería del software. 2. Medidas del Producto 3. Modelos y métricas del Proceso 4. Producto 53 2. Métricas del Producto 21 2.1 Métricas Méti internas. 2.2 Métricas externas. 2.2.1 Defectos del software. 2.2.2 Fiabilidad del software y modelos. 2.3 Métricas en O.O. M.E. Manso. 1

2.1 Métricas internas Producto 54 Métricas de tamaño Utilidad Cómo estimación del trabajo realizado Para predecir esfuerzo y coste, y poder gestionar el trabajo a hacer Una gran parte de proyectos software entregan código (LDC) Se usan los puntos de función para medir cantidad de funcionalidad 55 LDC (Líneas De Código) Utilidad Fácil de calcular, una vez completado el programa Es un factor importante para modelos de desarrollo del software Puede medir la productividad: ldc/tiempo Puntos débiles Presentan sesgo contra los lenguajes de alto nivel Pueden motivar productividad artificial Pueden medir análogamente diseño, documentación, Especificaciones etc. 2

56 LDC (ii) Una LDC es cualquier línea de texto de programa, que no es comentario ni blanco, sin tener en cuenta el nº de sentencias o fragmentos de sentencia en esa línea. Esto incluye específicamente todas las cabeceras de programas, declaraciones y sentencias ejecutables y no ejecutables Para garantizar la consistencia: Se incluyen las líneas en blanco? No Los comentarios? No Se cuentan sentencias declarativas y ejecutables? Cuantas veces se cuenta el código reutilizable? 57 Ciencia del Software Token: unidad sintáctica más elemental distinguible por un compilador. No depende del lenguaje Programa: colección de tokens (operadores, operandos) Operador: símbolo o palabra clave que especifica una acción Operando: símbolo utilizado para representar datos Métricas N1: total de operadores usados N2: total de operandos usados n1: total de operadores diferentes n2: total de operandos diferentes n = Tamaño del vocabulario = n1 +n2 N =nºtotaldetokens=n1+n2 V= volumen = N log 2 (n1+n2) V* =(n+2)log 2 (n+2) L = nivel de abstracción = V* / V Vˆ = Nˆ log 2 (n) N ˆ = n1 log2( n1) + n2 log2( n2 ) 3

58 Ciencia del Software (ii) x:= y+1 if x=z then write (x) else read(z) n2 = 4 (x,y,z,1) n1 = 8 (:=,if..then, else, +,(),write,=,read) N2 = 7 N1 = 8 V ˆ = Nˆ log ˆ 212 N = 4log2 4 + 8log2 8 N= 15 n=12 V=15log 2 12 V* = 14 log 2 14 2 2 Cómo se cuenta el identificador de un procedimiento cuando se declara? cuándo se llama? Array(i,j) operando simple u operador aplicado a dos operandos? 59 Métricas de la Estructura Justificación La Calidad final de un producto dependerá de la estructura que tenga. En un abuso de lenguaje a estas medidas se les llama métricas de complejidad Métricas de código Complejidad de la estructura de un módulo Estructura del flujo de control Estructura del flujo de datos (comportamiento de los datos cuando interaccionan con el programa) Estructura de los datos Algunas son aplicables a otros niveles (diseño) 4

Complejidad Ciclomática McCabe V(G) 60 Flujo de control (G) Grafo dirigido (nodo=sentencia, arco = dirección) Sólo se consideran programas limpios Teorema de grafos fuertemente conectados nº de caminos linealmente independientes = arcos nodos + 1= nº de áreas en el plano 61 Complejidad Ciclomática(ii) G se convierte en un grafo fuertemente conectado uniendo conunarcola salida yla entrada V(G) = (arcos + 1) nodos +1 Nº de caminos linealmente independientes del programa Nº de decisiones BINARIAS o cambios en el flujo de control+1 5

62 Complejidad Ciclomática (iii) Se puede utilizar cómo indicador de la cobertura en las pruebas Tasa de eficiencia (pruebas) = (nº de objetos probados) / ( nº de objetos total) objetos --- caminos linealmente independientes Hay un orden débil total en G={diagramas de flujo}? ESCALA? 63 Métricas de D. Modulares Modularidad Reduce la complejidad a nivel humano Permite gestionar mejor la distribución de recursos Mejora la eficiencia Aumenta la fiabilidad, facilita detección/depuración de errores MA Facilita el mantenimiento Métricas inter e intramodulares Mb Mc Md Me Mf Mg 6

64 Métricas Intermodulares V(g) = nº de interfaces-nº de módulos +2 v(g) =1 si es un árbol puro MA v(g) >1 si hay reutilización Acoplamiento De datos Por sellado De control Por entorno de datos común Híbrido Mb Me Mc Base-datos Tipo de conexión Complejidad de la interfaz (recuento de tokens) Flujo de información (datos control o híbrido) Mf Md Mg 65 Métricas Intramodulares Cohesión ( escala?) Funcional Secuencial Comunicacional Procedural Temporal Lógica Coincidente (no es realmente un módulo) Abanico de entrada Abanico de salida (7 ± 2) Ámbito de control 7

66 Morfología (Yourdon y Constantine) Forma de una estructura modular, cuando se considera como un grafo dirigido: Cada nodo es un módulo Cada interfaz es un arco Tamaño: nº de nodos, nº de arcos o combinaciones de ambos Profundidad: camino mas largo desde la raíz hasta una de sus ramas (nº de subniveles) Anchura: máximo nº de nodos en un nivel dado Tasa arcos-nodos: medida de la densidad de las conexiones Medida de reutilización: V(G) - 1 = arcos - nodos + 1 67 Acoplamiento (Fenton y Melton) Métrica acorde con la teoría de la medida (ordinal) ACO(M1,M2) = i + N/(N+1) i: nº del peor acoplamiento entre M1 y M2 N: nº de interconexiones entre ambos. (i,j): i el orden de acoplamiento (en la escala ordinal mencionada), y j el nº de veces que está presente entre los pares de módulos (2,2) M1 M2 Aco(m1,m2) = 2 + 4/5 Aco(m2,m4) = 5 + 3/4 Aco(m1,m3) = 3 + 1/2 (2,2) (3,1) (5,1) M3 M4 (3,2) 8

68 Métricas del Sistema Modular Acoplamiento global de un sistema A tener en cuenta la escala de medida Cohesión global de un sistema #Módulos_ Funcionales / #Módulos Otras métricas? 69 Métricas del Flujo de Datos Complejidad de Henry-Kafura (IF4) Justificación Se vió correlación entre IF4 y el mantenimiento de datos (UNIX) Proceso de medición Clasificación de los flujos de información: local y global <A,x,B> A pasa a B x (flujo saliente de A y entrante de B) FI(A) = nº de ternas en las que A es el tercer término FO(A) = nº de ternas en las que A es el primer término IF4(G) = LDC(Mi) (FI(Mi) FO(Mi)) Métrica de Shepperd: IF(g) = (FIFO(Mi)) 2 9

Complejidad (IF4) 70 Problemas Difícil de interpretar: se mezclan atributos y escalas Es acorde con la teoría de la medición? Cuando da cero? Efecto del cuadrado Si no se considera, sistemas con pocos módulos y mucho flujo de información pueden dar mediciones similares a los que tienen muchos módulos con poco flujo de información (Tabla 3) Tabla 3. Sistema 1 Sistema 2 FI FO FIFO FIFO ** 2 FI FO FIFO FIFO **2 m1 2 3 6 36 3 4 12 144 m2 1 2 2 4 2 1 2 4 m3 3 1 3 9 1 1 1 1 m4 2 2 4 16 15 65 15 169 10