Está en la página 1de 57

CARRERA DE SISTEMAS

EVALUACIÓN DE SISTEMAS DE
INFORMACIÓN

CAPÍTULO 03.01 MÉTRICAS ASOCIADAS A LA


EVALUACIÓN

ING. MAURICIO ORTIZ


MORTIZO@UPS.EDU.EC
AGENDA

 Entidades, atributos, métricas en S.E


 Métricas del producto | Atributos internos
 Métricas del producto | Atributos externos
 Métricas del proceso
 Metodologías y estándares de medición de software
 Estudios empíricos

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


METAS ATRIBUTOS Y MÉTRICAS DE LA CALIDAD DEL
SOFTWARE
Meta Atributo Métrica Meta Atributo Métrica
Calidad del código Complejidad Complejidad ciclomática
Calidad de los Número de modificadores ambiguos (por
requerimientos Ambigüedad ejemplo, muchos, grande, amigable, etc.) Facilidad de
Completitud Número de TBA y TBD mantenimiento Factores de diseño
Comprensibilidad Número de secciones y subsecciones Comprensibilidad Porcentaje de comentarios internos

Volatilidad Número de cambios por requerimiento Convenciones variables de nomenclatura


Tiempo (por actividad) cuando se solicita un
cambio
Reusabilidad Porcentaje de componentes reutilizados
Número de requerimientos no trazables hasta
Trazabilidad el diseño o código Documentación Índice de legibilidad
Claridad del modelo Número de modelos UML Eficacia del control Porcentaje de personal por hora y por
de calidad Asignación de recursos actividad
Número de páginas descriptivas por modelo
Número de errores de UML
Tiempo de terminación real versus lo
Calidad del diseño Integridad Existencia del modelo arquitectónico
Tasa de finalización planeado
Completitud de Número de componentes que se siguen hasta
componentes el modelo arquitectónico Eficacia de la revisión Medición de la revisión
Número de errores de importancia crítica
Complejidad del diseño del procedimiento
Eficacia de las pruebas encontrados
Complejidad de la Número promedio de pasos para llegar a una
interfaz función o contenido normal
Distribución apropiada Esfuerzo requerido para corregir un error
Patrones Número de patrones utilizados Origen del error

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


ENTIDAD

 Objeto que va a ser caracterizado a través de la medición de sus atributos


 Entidades a medir en Ingeniería de Software
 Producto
 Cualquier artefacto, producto o entregable que resulte de los procesos de Ingeniería de Software
 Ejemplos: SRS, diseños UML, código fuente.
 Proceso
 Todas las actividades del ciclo de vida del software
 Conocer el estado de los procesos y cómo se llevan a cabo
 Ejemplos: Elicitación, especificación, diseño, implementación, metodologías de construcción
 Recurso
 Cualquier entrada de una actividad de un proceso.
 Ejemplos: Licencias, computadores, personal, infraestructura.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


ATRIBUTO

 Característica medible de una entidad


 Los atributos de una entidad (proceso, producto o recurso) pueden ser de dos tipos:
 Internos
 Se pueden medir directamente a partir de la entidad
 Sirven para la medición de atributos externos

 Externos
 Atributos que relacionan a las entidades con el entorno.
 Se miden mediante métricas indirectas
 Suelen relacionarse con la Calidad

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


EJEMPLOS DE MÉTRICAS

 Producto
 Atributos Internos: Tamaño, acoplamiento, cohesión, reutilización, número de casos, porcentaje de cobertura de
pruebas.
 Atributos Externos: Calidad, legibilidad, complejidad, facilidad de mantenimiento, fiabilidad.
 Proceso
 Atributos Internos: Tiempo, esfuerzo, número de requisitos, número de errores
 Atributos Externos: Calidad, coste, estabilidad
 Recurso
 Atributos Internos: Edad, salario, # personas, coste, # licencias, marca, especificaciones técnicas
 Atributos Externos: Productividad, experiencia, usabilidad, fiabilidad

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICA/MEDIDA

 Evaluación cuantitativa del grado en el cual un producto o proceso de software posee un atributo
determinado
 Tipos de métricas de software
 Directas: Obtenidas directamente de la entidad. Ej: longitud de código, número de defectos
 Indirectas: Derivadas de una o más métricas. Ej: densidad de defectos
 Objetivas: Valor independiente del operador
 Subjetivas: La persona que realiza la medición introduce factores de juicio en el resultado

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE PRODUCTO | ATRIBUTOS INTERNOS

 Métricas del tamaño de los sistemas


 Métricas de la complejidad del software
 McCabe
 Halstead
 Fan-In / Fan-Out
 Métricas de la documentación
 Métricas de la reutilización
 Métricas de la eficiencia

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DEL TAMAÑO DE LOS SISTEMAS (LOC)

 Se utilizan como umbrales o indicadores de posibles problemas.


 McCabe establece que si una función, procedimiento o método excede las 60 líneas es más propensa a tener errores.
 Líneas de código (LoC)
 Más utilizadas por su facilidad y simplicidad de cálculo.
 Existen variantes:
 DSI: Delivered Source Instruction (número de sentencias efectivas)
 NCLoC: Líneas no comentadas
 CLoC: Líneas comentadas
 Indicador de densidad de comentarios
 DoC=CLoC/(LoC+CLoC)
 SIZE1
 Número de puntos y coma
 Se creo para evitar el problema de la ambigüedad de de LoC

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DEL TAMAÑO DE LOS SISTEMAS (PUNTOS
FUNCIÓN)

1. Determinar el tipo de conteo de puntos de


función
2. Identificar los componentes funcionales que
formarán parte el conteo.
3. Identificar las transacciones de negocio
4. Identificar los componentes de datos
5. Determinar el conteo de puntos función

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DEL TAMAÑO DE LOS SISTEMAS (PUNTOS DE
CASOS DE USO)

 UUCP = UAW + UUCW


 Desarrollado en 1993 por Gustav Kamer, bajo la
supervisión de Ivar Jacobson  UUCP: Puntos de casos de uso sin ajustar.
 UAW: Factor de peso de los actores sin ajustar.
 Se asigna una complejidad a los casos de uso
 UUCW: Factor de peso de los casos de uso sin
 Interacciones entre usuarios y sistemas
ajustar.
 Se asigna una complejidad a los actores
 UCP = UUCP x TCF x EF
 Dependiendo si son personas o sistemas
 UCP: Puntos de casos de uso ajustados.
 También se tiene en cuenta factores  TCF: Factores técnicos.
ambientales y técnicos
 EF: Factores ambientales.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE LA COMPLEJIDAD DEL SOFTWARE (MCCABE)

 Complejidad ciclomática
 Número de caminos independientes dentro de un método.
 NO mide ciclos.
 Fórmula: Número de condiciones + 1.
 Resultados
 1-10 Programa Simple, sin mucho riesgo.
 11-20 Programa de riesgo moderado.
 21-50 Programa de alto riesgo.
 50 Programa de muy alto riesgo, no se puede probar.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE LA COMPLEJIDAD DEL SOFTWARE (HALSTEAD)

 Estas métricas se calculan estáticamente a


partir del código.  Fórmulas
 Métricas  Vocabulario n=n1 + n2
 Operadores = Palabras reservadas, aritméticos,  Longitud N=N1 + N2
asignación y lógicos
 Volumen V=Longitud * Log2n
 Operandos = Constantes, variables e
identificadores  Dificultad D=(n1/2) * (N1/n2)
 n1= #TotalOperadoresDistintos  Esfuerzo mental E=Dificutad * Volumen
 n2 = #TotalOperandosDistintos  Errores B=Volumen / 3000
 N1= #TotalOperadores  Tiempo T=E / 18
 N2 = #TotalOperandos

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE LA COMPLEJIDAD DEL SOFTWARE (FAN-IN
FAN-OUT)
 Cuenta el número de llamadas entre módulos
 FAN-IN de m
 Concentración
 Número de flujos que terminan en m
 FAN-OUT de m
 Expansión
 Número de flujos que salen de m
 Complejidad de un módulo
 longitud = número de sentencias del módulo m
 MHK = longitud(m) * [fan-in(m) * fan-out(m)]2

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE LA COMPLEJIDAD DEL SOFTWARE
(ARQUITECTURAS DE SOFTWARE)

 Tamaño = n + a
 n es el número de nodos
 a es el número de arcos
 Profundidad = trayectoria más larga desde el
nodo raíz (superior) hasta un nodo hoja.
 Ancho = número máximo de nodos en cualquier
nivel de la arquitectura.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE LA DOCUMENTACIÓN

 Indicador Gunning-Fog  Indicador Flesch

 Fórmula: 0,4*[(#TotalPalabras /  Fórmula: 206,835 – 1,015*(#TotalPalabras /


#TotalOraciones)+100*(#TotalPalabrasComplejas / #TotalOraciones) – 84,6*(#TotalSílabas /
#TotalPalabras)] #TotalOraciones)
 #Total de palabras complejas = 3 o más sílabas.  Resultados
 Resultados  Más de 90: Legible por prácticamente el 99,99% de la
población que sabe leer.
 Menos de 8: Legible por prácticamente el 99,99% de la
población que sabe leer.  60-90: Legible por cualquier persona que tenga una
educación baja-media y que lea al menos un poquito.
 8-12: Legible por cualquier persona que tenga una
educación baja-media y que lea al menos un poquito.  30-60: Requiere de una capacidad lectora decente y
pide más atención de lo habitual para comprenderlo
 Más de 12: Requiere de una capacidad lectora
decente y pide más atención de lo habitual para  0-30: Lectura muy difícil. Un graduado universitario
comprenderlo. entiende mejor el texto.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE LA DOCUMENTACIÓN SRS

 Especificidad (falta de ambigüedad)


 Completitud
 Corrección  Se supone que existen nr requerimientos en una
 Comprensibilidad especificación, tales que: nr = nf + nnf
 Verificabilidad  Especificad = nui / nr
 Consistencia interna y externa  nui = número de requisitos para los cuales todos los
revisores tienen interpretaciones idénticas.
 Factibilidad
 Completitud = nc / nc * nnv
 Concisión  nc = número de requerimientos que se validaron como
 Rastreabilidad correctos.
 Modificabilidad  nnv = número de requerimientos que no se han validado.

 Precisión
 Reusabilidad

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE LA REUTILIZACIÓN

 La reutilización afecta de forma positiva a la calidad y productividad


 Porcentaje de reutilización
 (Loc reutilizados/LoC totales)X100
 No se debe confundir con código duplicado

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE LA EFICIENCIA

 Utilizadas en sistemas de tiempo real


 El tiempo de ejecución es una métrica externa.
 Complejidad de Orden
 Mide únicamente la eficiencia del código como métrica interna
 O(n)= número de operaciones que realiza el algoritmo dada una entrada n.
 Ejemplos con búsquedas:
 Dentro de una arreglo de n números realizar una búsqueda simple, en el peor de los casos, el algoritmo necesitará recorrer
los n números por lo tanto la complejidad de orden es O(n).
 Dentro de una arreglo de n números realizar una búsqueda binaria, en el peor de los casos, el algoritmo necesitará recorrer
los log2n números por lo tanto la complejidad de orden es O(log2n).

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE PRODUCTO | ATRIBUTOS EXTERNOS

 Miden la visión externa del producto


 También denominadas factores de calidad
 Tiempo medio entre fallas
 Densidad de errores
 Problemas del cliente
 Satisfacción del cliente
 ISO/IEC TR 9126-2:2003
 Software engineering -- Product quality -- Part 2: External metricsLo que percibe el cliente.
 ISO/IEC 25023:2016 Systems and software engineering -- Systems and software Quality Requirements and Evaluation
(SQuaRE) -- Measurement of system and software product quality.
 Funcionalidad, Fiabilidad, Usabilidad, Eficiencia, Mantenibilidad, Portabilidad.
 Evoluciona dentro del estándar ISO/IEC 14598

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


ISO/IEC 9126

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS PARA ESPECIFICAR REQUERIMIENTOS NO
FUNCIONALES
Propiedad Medida
Rapidez Transacciones/segundo procesadas
Tiempo de respuesta usuario/evento
Tiempo de regeneración de pantalla
Tamaño Mbytes
Número de chips ROM
Facilidad de uso Tiempo de capacitación
Número de cuadros de ayuda
Fiabilidad Tiempo medio para falla
Probabilidad de indisponibilidad
Tasa de ocurrencia de falla
Disponibilidad
Robustez Tiempo de reinicio después de falla
Porcentaje de eventos que causan falla
Probabilidad de corrupción de datos en falla
Portabilidad Porcentaje de enunciados dependientes de objetivo
Número de sistemas objetivo

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE PROCESO

 Internas
 Tiempo  Modelos de mejora de procesos
 Esfuerzo  CMMI
 Incidentes  ISO/IEC 15504 SPICE
 Cambios  ISO 9000
 Externas  Six Sigma
 Facilidad de observación  COBIT

 Estabilidad del proceso


 Costes

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE RECURSOS

 Herramientas
 Productividad
 Coste, tipo de licencia, curva de aprendizaje,
 Tamaño = Líneas de código o Puntos Función reutilización en otros proyectos
 Esfuerzo = Persona por mes  Materiales
 Productividad=Tamaño/Esfuerzo  Oficinas, material tangible, desplazamientos, aire
 Personal acondicionado, etc. Influyen en el costo y por lo
tanto en la productividad del producto
 Salario, experiencia, edad, productividad individual
 Métodos
 Complejidad de la comunicación entre el equipo
(métricas Hewlelt-Packad)  Análisis post-mortem del proyecto y los métodos
usados

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


METODOLOGÍAS Y ESTÁNDARES DE MEDICIÓN DE SOFTWARE

 De debe definir “que mejorar para identificar que medir”


 Permiten reducir el número de métricas a utilizar
 Identificar entidades y atributos de medición debe realizarse mediante metodologías y estándares
 Goal Question Metric (GQM)
 Practical Software Measurement (PSM)
 ISO/IEC/IEEE 15939:2017 Systems and software engineering -- Measurement process
 IEEE 1061-1998 - IEEE Standard for a Software Quality Metrics Methodology

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


GOAL QUESTION METRIC | GQM

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


APLICACIÓN DE GQM

 Pregunta
Analizar DB relacionales
 ¿Cómo influye la complejidad de las tablas en la
Con el propósito de Entender mantenibilidad de las BD relacionales?
Con respecto a Mantenibilidad  Métricas
Desde el punto de vista de Los diseñadores de BD  NA = #AtributosTabla
En el contexto de Desarrollo y mantenimiento de BD  NFK = #ClavesForáneas
 RFK = NFK / NA

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


PRACTICAL SOFTWARE MEASUREMENT | PSM

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


ISO/IEC/IEEE 15939:2017
SYSTEMS AND SOFTWARE ENGINEERING -- MEASUREMENT PROCESS

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


IEEE 1061-1998 - IEEE STANDARD FOR A SOFTWARE
QUALITY METRICS METHODOLOGY

 Establecer los requisitos de calidad del


software.
 Identificar las métricas de calidad del software
mediante la aplicación de un marco de métricas
de calidad
 Implementar las métricas de calidad.
 Analizar los resultados
 Evaluar los resultados

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


PROGRAMA DE MÉTRICA DE SOFTWARE (SEI)

1. Identificar las metas empresariales. 7. Identificar los elementos de datos que se


recopilarán para construir los indicadores que
2. Identificar lo que se quiere conocer o aprender. ayuden a responder las preguntas.
3. Identificar las submetas. 8. Definir las medidas que se van a usar y hacer
4. Identificar las entidades y atributos relacionados operativas estas definiciones.
con las submetas. 9. Identificar las acciones que se tomarán para
5. Formalizar las metas de medición. implementar las medidas.

6. Identificar preguntas cuantificables y los 10. Preparar un plan para la implantación de las
indicadores relacionados que se usarán para medidas.
ayudar a lograr las metas de medición.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


ESTUDIOS EMPÍRICOS

 Encuestas
 Documentar relaciones y resultados
 Una de las herramientas más útiles para recabar un buen número de datos que posteriormente serán
analizados.
 Casos de estudio
 Identificar y documentar factores clave que pueden afectar los resultados de una actividad.
 Experimentos formales
 Investigar de forma controlada, rigurosa y cuantitativa aquellos factores que afectan a las actividades a realizar.
 Definición, planificación, operación, interpretación, conclusiones y presentación de resultados

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


REFERENCIAS

 Rodríguez, D., Ángel Sicilia, M., & Sánchez, S. (2012). Ingeniería de Software Un enfoque desde la guía
SWEBOK. México: Alfaomega. Capítulo 3
 Pantaleo, G., & Rinaudo, L. (2015). Ingeniería de software. Alfaomega Grupo Editor. Capítulo 15, 22.2
 Muñoz, C. C., Velthuis, M. G. P., & de la Rubia, M. Á. M. (2010). Calidad del producto y proceso software.
Editorial Ra-Ma.
 Piattini Velthuis, M. G., Garcia Rubio, F., & Caballero Muñoz-Reja, I. (2015). Calidad de sistemas de
información. Alfaomega Ra-Ma,. Capítulo 8, 12, 14, 15, 16 y 18.
 Pressman, R. S. 7ed. (2010). Software engineering: a practitioner's approach. Palgrave Macmillan. Capítulo
9.5, 15.3, 16.3, 23, 25, 26
 Sommerville, I. 9 ed. (2011). Software engineering. Addison-wesley. Capítulo 4.1.2, 12.3, 15.2, 24.4, 26.2
 Métricas de software, Moreno M., Departamento de Informática y Automática. Universidad de Salamanca
 Vargas Torres, L. Á., Torres, Y., & Emilio, H. (2011). Herramienta para estimar el tamaño de software por el
método de puntos de función.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


CARRERA DE SISTEMAS
EVALUACIÓN DE SISTEMAS DE
INFORMACIÓN

CAPÍTULO 03.02 MÉTRICAS ASOCIADAS A LA


EVALUACIÓN

ING. MAURICIO ORTIZ


MORTIZO@UPS.EDU.EC
AGENDA

 Jerarquía de métricas
 Métricas de producto Orientadas a Objetos
 Métricas de producto de Base de Datos
 Métricas de producto para web
 Métricas de revisión
 Métricas de mantenimiento
 Polimétricas
 Desarmonías (Code smells)

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


JERARQUÍA DE MÉTRICAS

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


ATRIBUTOS DE LAS MÉTRICAS DE SOFTWARE EFECTIVAS

 Simple y calculable
 Empírica e intuitivamente convincente.
 Congruente y objetiva
“Se han propuesto cientos de métricas para el
 Constante en su uso de unidades y software de computadora, pero no todas brindan
dimensiones. apoyo práctico al ingeniero de software”
 Independiente del lenguaje de programación. Roger Pressman
 Un mecanismo efectivo para retroalimentación
de alta calidad.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS MOOSE (CK)

 Acoplamiento entre objetos (CBO)


 Métodos ponderados por clase (WMC)
 Mide el esfuerzo requerido para probar la clase.
 Calcula la complejidad de la clase.
 Una clase se acopla con otra si los métodos de una clase
 Clases con menos WMC son mejores. usan los métodos o atributos de la otra clase.
 Si todos los métodos de la clase tiene complejidad=1.  Número de atributos de tipo Objeto.
Entonces, WMC=NúmeroMétodos
 Respuesta para una clase (RFC)
 Profundidad del árbol de herencia (DIT)
 Número de métodos que se pueden invocar en respuesta
 Calcula qué tan abajo está declarada una clase en la a un mensaje en una clase.
jerarquía de herencia.
 Si RFC aumenta, la complejidad general del diseño de la
 Cuenta directamente los niveles clase aumenta y se vuelve difícil de entender.
 Número de hijos (NOC)  Falta de cohesión en los métodos (LCOM)
 Cuántas subclases heredarán los métodos de la clase  Grado en el cual los métodos hacen referencia a los
padre atributos de la clase
 Indica el nivel de reutilización

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS MOOD

 Factor de herencia de método (MIF)


 Cociente entre la suma de todos los métodos
 Factor de ocultamiento del método (MHF) heredados del sistema y el número total de métodos
 Proporción entre métodos privados y protegidos  Se enfoca en medir la reutilización
contra el número total de métodos
 Factor de herencia del atributo (AIF)
 Se enfoca en medir la encapsulación
 Cociente entre la suma de todos los atributos
 Factor de ocultación del atributo (AHF) heredados del sistema y el número total de atributos
 Cociente entre los atributos privados del sistema y el  Se enfoca en medir la reutilización
número total de atributos.
 Factor de polimorfismo (PF)
 Se enfoca en medir la encapsulación
 Cociente entre el número de métodos heredados
redefinidos dividido entre el máximo número de
situaciones polimórficas distintas.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS LORENZ & KIDD

 Métricas de Herencia
 Métricas de tamaño  Número de Métodos Sobrecargados (NMO)
 Número de Métodos de Instancia Públicos (PIM)  Número de Métodos Heredados (NMI)
 Servicios para otras clases  Número de Métodos Añadidos (NMA)
 Número de Métodos de Instancia (NIM)  Métodos que se definen en las subclases
 Conteo de todos los métodos de una clase  Índice de Especialización para una clase (SIX)
 Número de Variables de Instancia (NIV)  En que medida las subclases redefinen el comportamiento de
sus superclases.
 Conteo de todos los atributos
 (NúmeroMetodosRedefinidos * AnidamientoJerarquía) /
 Número de Métodos de Clase (NCM) NúmeroTotalMétodos
 Conteo de los métodos static  Métrica de características internas de una clase
 Número de Variables de Clase (NVV)  Promedio de Parámetros por Método (APPM)
 Conteo de los atributos static  (NúmeroTotalParametros) / NúmeroTotalMétodos

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE ACOPLAMIENTO

 K debe derivarse de manera empírica.


 M = di + (a * ci) + do + (b * co) +gd +(c*gc) +w + r
 di =número de parámetros de datos de entrada
 ci =número de parámetros de control de entrada
 do =número de parámetros de datos de salida
 El acoplamiento de módulo proporciona un indicio de  co =número de parámetros de control de salida
cuán “conectado” está un módulo con otros módulos
 gd =número de variables globales usadas como datos
 Indicador de Acoplamiento = k / M
 gc =número de variables globales usadas como control
 w numero de módulos llamados (fan-out)
 r numero de módulos que llaman al modulo bajo
consideración ( fan-in)
 Los valores para k, a, b y c deben derivarse de manera
empírica.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE COHESIÓN

 Símbolos pegamento (glue tokens).


 Este conjunto de tokens de datos se encuentra en
 Rebanada de datos (data slice). una o más rebanadas de datos.

 Es una marcha hacia atrás a través de un módulo  Símbolos superpegamento (superglue tokens).
que busca valores de datos que afecten la  Estos tokens de datos son comunes a cada
ubicación del módulo donde comenzó la marcha. rebanada de datos en un módulo.
 Símbolos de datos (data tokens).  Pegajosidad (stickiness).
 Las variables definidas por un módulo pueden  La pegajosidad relativa de un token pegamento es
definirse como tokens de datos para el módulo. directamente proporcional al número de rebanadas
de datos que enlaza.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


METRICAS DE PAQUETES

 Acoplamiento eferente (Ce)


 Número de clases en un paquete dado, que dependen de las clases de otros paquetes
 Los acoplamientos eferentes señalan hacia afuera
 Acoplamiento aferente (Ca)
 El número de clases en otros paquetes que dependen de las clases dentro del paquete.
 Los acoplamientos aferentes señalan hacia adentro.
 Inestabilidad (I)
 Medir la susceptibilidad relativa de la clase a los cambios.
 Ce / (Ce + Ca)
 Abstracción (a)
 Número de clases abstractas en el paquete para el número total de clases

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


CLASES UML

 Número total de clases (NC)


 Número total de atributos (NA)  Número total de relaciones de generalización
(NGen)
 Número total de métodos (NM)
 Valor máximo DIT (MaxDIT)
 Número total de relaciones de asociación
 DIT es la longitud el camino más largo desde la
(NAssoc)
clase hasta la raíz de la jerarquía
 Número total de relaciones de agregación
 Valor máximo HAgg (MaxHAgg)
(NAgg)
 HAgg para una clase dentro de una jerarquía de
 Número total de relaciones de dependencia agregación es la longitud del camino más largo
(NDep) desde la clase hasta las hojas

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


CASOS DE USO Y ESTADOS UML

Casos de Uso Diagrama de estados


 Número de casos de uso (NCU)  Número de estados (numSta)
 Número de actores (NA)  Número de acciones (numAction)
 Número de relaciones de inclusión (NI)  Número de estados para cada clase (totSta)
 Número de relaciones de extensión (NE)  Número de acciones para una clase (totAction)

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MODELOS LÓGICOS DE BASES DE DATOS

 Número de atributos de una tabla NA(T)


 Número de claves foráneas de una tabla NFK(T)
 Profundidad del árbol referencial DRT(T)
 Ratio de claves ajenas RFK(T)
 NFK(T) / NA(T)
 Número de tablas NT
 Número de tablas en tercera forma normal NT3NF
 Ratio de normalidad NR
 NT3NF / NT

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MODELOS CONCEPTUALES DE BASES DE DATOS

 Corrección
 Completitud
 Número de violaciones a las formas normales.
 Número de elementos que no corresponden con
requisitos de usuario  Simplicidad
 Número de requisitos no representados en el modelo  Número entidades
de datos
 Número entidades y relaciones
 Integridad
 Número de constructores
 Número de reglas de negocio que no se hacen
cumplir por el Modelo de Datos  Integración
 Flexibilidad  Número de conflictos con el modelo de datos
corporativo.
 Costes estimados de los cambios.
 Implementabilidad
 Comprensibilidad
 Estimación del coste de desarrollo.
 Valoración sobre la comprensibilidad del modelo

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE PRODUCTO PARA WEB

 Número de sistemas externos puestos en


 Número de páginas web estáticas.
interfaz.
 Número de páginas web dinámicas.
 Número de objetos de contenido estáticos.
 Número de vínculos de página internos.
 Número de objetos de contenido dinámicos.
 Número de objetos de datos persistentes.
 Número de funciones ejecutables.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE INTERFAZ PARA WEB

Métrica sugerida Métrica sugerida Descripción

Complejidad de plantilla Número de regions distintas definidas por una interfaz

Complejidad de región de plantilla Número promedio de distintos vínculos por región

Complejidad de reconocimiento Número promedio de distintos ítems que el usuario debe buscar antes de realizar una navegación o decidir la entrada de datos

Tiempo de reconocimiento Tiempo promedio (en segundos) que tarda un usuario en seleccionar la acción adecuada para una tarea determinada

Esfuerzo de escritura Número promedio de golpes de tecla requeridos para una función específica

Esfuerzo de toma de ratón Número promedio de tomas de ratón por función

Complejidad de selección Número promedio de vínculos que pueden seleccionarse por página

Tiempo de adquisición de contenido Número promedio de palabras de texto por página web

Carga de memoria Número promedio de distintos ítems de datos que el usuario debe recordar para lograr un objetivo específico

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE MANTENIMIENTO

 MT = número de módulos en la liberación actual


 Índice de madurez de software (IMS)
 Fc = número de módulos en la liberación actual
 Proporciona un indicio de la estabilidad de un
que cambiaron
producto de software
 IMS = (MT – (Fa +Fc + Fd))/MT  Fa = número de módulos en la liberación actual
que se agregaron
 Conforme el IMS tiende a 1.0, el producto
comienza a estabilizarse.  Fd = número de módulos de la liberación
anterior que se borraron en la liberación actual

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS DE REVISIÓN

 Tamaño del producto del trabajo (TPT)


 Medición del tamaño del producto del trabajo que se ha
 Esfuerzo de preparación (Ep) revisado (por ejemplo, número de modelos UML o número
 Esfuerzo (en horas-hombre) requerido para revisar un de páginas de documento o de líneas de código).
producto del trabajo antes de la reunión de revisión real.  Errores menores detectados (Errmenores)
 Esfuerzo de evaluación (Ea)  Número de errores detectados que pueden clasificarse
 Esfuerzo requerido (en horas-hombre) que se dedica a la como menores (requieren menos de algún esfuerzo
revisión real. especificado para corregirse).

 Esfuerzo de la repetición (Er)  Errores mayores detectados (Errmayores)


 Esfuerzo (en horas-hombre) que se dedica a la corrección  Número de errores encontrados que pueden clasificarse
de los errores descubiertos durante la revisión. como mayores (requieren más que algún esfuerzo
especificado para corregirse).
 Errrevisión = Ep + Ea + Er
 Errtot = Errmenores + Errmayores
 Densidad del error = TPT/ Errtot

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


MÉTRICAS PARA ORGANIZACIONES PEQUEÑAS

 Tiempo transcurrido (horas o días) desde el momento en


el que se hace una petición hasta que la evaluación está
completa, (tcola)
 Esfuerzo (persona-horas) para realizar la evaluación,
 “La gran mayoría de las organizaciones de desarrollo de (Weval)
software tienen menos de 20 personas en sus
departamentos de software […] No es razonable, y en la  Tiempo transcurrido (horas o días) desde la conclusión de
mayoría de los casos es irreal, esperar que tales la evaluación hasta la asignación de la orden de cambio al
organizaciones desarrollen programas de métricas de personal, (teval).
software exhaustivos.”  Esfuerzo requerido (persona-horas) para hacer el cambio,
Roger Pressman (Wcambio).

 Eficiencia de remoción de defecto  Tiempo requerido (horas o días) para hacer el cambio,
(tcambio).
 Medida de mejora del proceso
 Errores descubiertos durante el trabajo para hacer el
 Ecambio / (Ecambio + Dcambio) cambio, (Ecambio).
 Defectos descubiertos después de liberar el cambio al
cliente base, (Dcambio).

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


POLIMÉTRICAS

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


DESARMONIAS DE IDENTIDAD (CLASES)

 Feature Envy (Fowler)


 Brain Method
 Los métodos están más interesados en otras
 El método tiene una complejidad muy alta y
clases que en su propia clase.
contiene la mayoría de las funcionalidades de la
 Data Class (Fowler) clase.

 Agrega datos pero no comportamiento.  A veces incluso la funcionalidad de todo el sistema

 Síntoma de una mala encapsulación de datos y  Brain Class


funcionalidad
 Contiene muchos “Brain method”
 God class (Fowler)
 Significant Duplication (Fowler)
 Interactúa con muchas otras clases, centraliza el
 Alta duplicación de código
funcionamiento y realiza demasiado trabajo.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


DESARMONÍAS DE COLABORACIÓN (MENSAJES)

 Shotgun Surgery (Fowler)


 Un número excesivo de operaciones están ligadas
a un método de una clase proveedora.
 Intensive Coupling (Fowler)
 Es la comunicación excesiva entre un método
cliente y sus clases proveedoras.
 Dispersed Coupling
 Es una operación que está excesivamente ligada a
muchas otras operaciones en el sistema,
contenidas en métodos dispersos entre varias
clases

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


DESARMONÍAS DE CLASIFICACIÓN (HERENCIA)

 Tradition Breaker
 Refused Parent Bequest (Fowler)
 Una clase derivada proporciona un conjunto de
 La clase secundaria solo usa parcialmente o no
servicios que no están relacionados con los de su
usa métodos heredados.
clase base.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN


REFERENCIAS

 Rodríguez, D., Ángel Sicilia, M., & Sánchez, S. (2012). Ingeniería de Software Un enfoque desde la guía SWEBOK. México:
Alfaomega. Capítulo 3
 Pantaleo, G., & Rinaudo, L. (2015). Ingeniería de software. Alfaomega Grupo Editor. Capítulo 15, 22.2
 Muñoz, C. C., Velthuis, M. G. P., & de la Rubia, M. Á. M. (2010). Calidad del producto y proceso software. Editorial Ra-Ma.
 Piattini Velthuis, M. G., Garcia Rubio, F., & Caballero Muñoz-Reja, I. (2015). Calidad de sistemas de información. Alfaomega
Ra-Ma,. Capítulo 8, 12, 14, 15, 16 y 18.
 Pressman, R. S. 7ed. (2010). Software engineering: a practitioner's approach. Palgrave Macmillan. Capítulo 9.5, 15.3, 16.3,
23, 25, 26
 Sommerville, I. 9 ed. (2011). Software engineering. Addison-wesley. Capítulo 4.1.2, 12.3, 15.2, 24.4, 26.2
 Ditz, L. M. (2016). Análisis de dependencia entre refactorings.
 Métricas de software, Moreno M., Departamento de Informática y Automática. Universidad de Salamanca
 Vargas Torres, L. Á., Torres, Y., & Emilio, H. (2011). Herramienta para estimar el tamaño de software por el método de
puntos de función.

EVALUACIÓN DE SISTEMAS DE INFORMACIÓN

También podría gustarte