RESULTADOS DE LA APLICACIÓN DE CUATRO METRICAS AL PROYECTO SISTEMA DE INFORMACION DE ELECCIONES DE

RESPRESENTANTES ESTUDIANTILES

MARIA DE LOS ANGELES CASTRO DURAN

1150293

KATHY SHIRLEY JAIMES OJEDA

1150372

MSc. JUDITH DEL PILAR RODRIGUEZ TENJO

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER

FACULTAD DE INGENIERIA

PROGRAMA DE INGENIERIA DE SISTEMAS

SAN JOSE DE CUCUTA

2016

1. MÉTRICA PARA EL MODELO DE DATOS

JUSTIFICACION

Según la ISO 9126 la calidad del producto está influenciada por la complejidad del mismo. Con el propósito de medir la calidad del modelo de datos implementado en SIERE se han utilizado un conjunto de métricas comúnmente aceptadas y cuyo objetivo es el poder medir la complejidad del esquema estrella y así poder tener un indicativo objetivo de la calidad del mismo.

Se han fijado 2 niveles distintos:

• Nivel de tabla.

• Nivel de estrella.

METRICAS A NIVEL DE TABLA

NA= Representa el número de atributos de una tabla

NFK=Representa el número de claves ajenas de una tabla

Tabla NA NFK

CalendarioElectoral 12 8Candidato 17 5Acta 10 5Archivo 8 4Jurado 6 3Clavero 6 3Mesa 7 3Urna 4 2Escrutador 4 1Evento 5 2Model 6 1

METRICAS A NIVEL DE ESTRELLA

JUSTIFICACION

El objetivo de las métricas es poder medir la complejidad del esquema de estrella y así poder tener un indicativo objetivo de la calidad del sistema.

El nivel de estrella propone unos elementos principales de un almacén de datos siendo detallados así:

NDTS= representan el número de tablas dimensionales de una estrella

NTS=representan el número de tablas de la estrella

NADTS=representan el número de atributos de las tablas dimensionales de una estrella.

NAFTS=representan el número de atributos de la tabla de hechos de la estrella.

NAS=representan el número de atributos de la estrella.

NAS= NAFTS + NADTS

NFKS=Número de claves ajenas de una estrella

NFKS=NFK(FT) + ∑ NDT NFK(DTi)

i=1

FT es la tabla de los hechos de la estrella y DTi es la tabla dimensional i de la estrella

RSAS= Representa el ratio de atributos de la estrella. Número de atributos de las tablas dimensionales dividido por el número de atributos de la tabla de los hechos.

RSAS= NADTS/ NAFTS

RFKS= Ratio de claves ajenas. Número de atributos de la tabla de hechos que son claves ajenas.

RFKS= NFK(FT) / NAFT(FT)

Donde FT es la tabla de hechos de la Estrella.

CONCLUSIONES

El diseño de esquemas en estrella permite implementar la funcionalidad de una base de datos multidimensional utilizando una clásica base de datos relacional.

La calidad del modelado de datos permite tener en enfoca tres aspectos: la calidad del modelado conceptual, la calidad del modelo lógico y la calidad del modelado físico.

El modelo en estrella permite una comprensión fácil de los datos.

Al analizar la complejidad de una tabla se deben tener en cuenta tres características: número de atributos de una tabla, numero de claves ajenas, y el ratio de claves de una tabla así mismo para analizar la relación entre tablas se deben tener presentes el número de tablas, el número de atributos y número de claves ajenas.

MÉTRICAS DE PUNTO DE FUNCIÓN

La métrica de punto de función (PF) se utiliza con el objetivo principal de medir la funcionalidad que entra al sistema de información. Esta información se utiliza para estimar el costo requerido para diseñar, codificar y probar el costo del software, para predecir errores posibles en el proceso de pruebas, y para prever el número de componentes que hacen parte del proyecto. Es por esta razón que esta métrica es útil durante el modelo de requerimientos.

Esta métrica se utiliza en SIERE por medir las bases iniciales. En base a los resultados podemos verificar claramente la consistencia del proceso realizado con los requerimientos, para proceder al diseño.

Número de Entradas externas (EE): Entradas originadas por un usuario o transmitidas desde otra aplicación:

● Ingreso de calendario electoral● Ingreso de candidatos● Ingreso de mesa de votación● Ingreso de claveros● Ingreso de escrutadores● Ingreso de tarjetón electoral● Ingreso de Jurados● Ingreso de Actas● Ingreso de Urnas

EE = 9

Número de Salidas externas (SE): Datos en la aplicación que proveen información al usuario:

● Consulta de calendario electoral● Consulta de candidatos● Consulta de jurados● consulta de escrutadores● consulta de urnas● consulta de mesas● consulta de tarjetón electoral● consulta de actas

● consulta de claveros

SE = 9

Número de Consultas Externas (CE): Entrada en línea que genera una respuesta automática. En este caso, las consultas del usuario, por lo tanto CE=1.

Número de Archivos Lógicos Internos (ALI): Agrupamiento lógico de datos en entradas externas. No aplica en este caso.

Número de archivos de interfaz externa (AIE): No aplica.

Valor de dominio Conteo Factor Ponderado ConteoSimple Promedio Complejo

Entradas Externas 9 3 4 6 20Salidas Externas 9 4 5 7 20

Consultas Externas 1 7 10 6 7Archivos Lógicos

Internos0 7 10 15 0

Archivos de Interfaz Externa

0 5 7 10 0

Conteo total 47Tabla 1. Relación de variables

Factores de ajuste de valor (FAV):

Característica Valor¿El sistema requiere respaldo y recuperación confiables? 5¿Se requieren comunicaciones de datos especializadas para transferir información hacia o desde la aplicación?

2

¿Existen funciones de procesamiento distribuidas? 1¿El desempeño es crucial? 4¿El sistema correrá en un entorno operativo existente enormemente utilizado?

4

¿La entrada de datos en línea requiere que la transacción de entrada se construya sobre múltiples pantallas u operaciones?

1

¿Los ALI se actualizan en línea? 4¿Las entradas, salidas, archivos o consultas son complejos? 3¿El procesamiento interno es complejo? 2¿El código se diseña para ser reutilizable? 4¿La conversión y la instalación se incluyen en el diseño? 3¿El sistema se diseña para instalaciones múltiples en diferentes organizaciones?

1

¿La aplicación se diseña para facilitar el cambio y su uso por parte del usuario?

4

¿El sistema requiere datos de entrada en línea? 4Total 47

Tabla 2. Factores de ajuste de valor

Con los valores calculados procedemos al conteo total

PF = conteo total x [0.65 + 0.01 x ∑ (Fi)]

PF = 47 x [0.65 + (0.01 x 36)]

PF = 48

En definitiva, la estimación es de 48 Puntos de función. Basados en este valor podemos estimar el tamaño global implementado partiendo de este cálculo. Lo importante de estos datos es que podemos planificar a partir de ellos siendo datos verificables y no estimaciones preliminares.

Líneas de código fuente (SLOC) =FP * LF

SLOC =FP (Puntos de Función Ajustados) * LF (Factor del Lenguaje PHP)

SLOC= 9667.35 * 38

SLOC= 367359,3

MÉTRICAS ORIENTADAS A OBJETOS

Las métricas para sistemas Orientados a Objetos deben de ajustarse a las características que distinguen el software Orientado a Objetos del software convencional. Estas métricas hacen referencia a el encapsulamiento, la herencia, complejidad de clases y polimorfismo, características primordiales del diseño del Sistema de Información SIERE.

· Aplicación: Conjunto de métricas CK

· Métodos ponderados por clase (MPC):

El MPC recoge la noción de complejidad. Para una clase C con M1, M2,…, Mn métodos con un peso de complejidad c1, c2,…cn respectivamente, se tiene que:

MPC = ∑ ci

Sin embargo, MPC en vez de definir una manera de calcular la complejidad, la deja libre a elección del equipo. En este caso utilizaremos la complejidad ciclomática:

· Iniciar sesión: 3

· Registrar Calendario Electoral: 2

· Editar calendario electoral : 2

Visualizar calendario electora: 1

Registrar candidatos: 2

Editar candidatos:2

Listar candidatos:1

Agregar acta:1

Registrar Jurados:2

Editar Jurados:2

Ver Jurados:1

Registrar tarjetón electoral:2

Editar tarjetón electoral:2

Ver tarjetón electoral:1

Registrar escrutador:2

Editar escrutador:2

Ver escrutador:1

Registrar mesa de votacion:2

Editar mesa de votación: 2

Ver mesa de votación: 1

Registrar Urna: 2

Editar urna: 2

Ver urna:1

·

Tamaño de Clase (TC)

Métrica expresada como el número de atributos (tanto atributos heredados como atributos privados de la Instancia) que están encapsulados en la clase.

Clase TCCalendario Electoral 12

Candidato 18Archivo 8

Acta 10Jurado 6

Administrador 4clavero 6mesa 6urna 3

escrutador 4Promedio 7.7

MÉTRICAS ORIENTADAS A CASOS DE USO

Como los puntos de función, los casos de uso se definen en etapas tempranas del proceso de desarrollo de software, lo que permite emplearlo en la estimación antes de iniciar las actividades significativas. Se emplea el criterio de puntos de casos de uso (UCP) como métrica para medir el esfuerzo y la complejidad de los mismos. Esta métrica permite estimar los niveles de complejidad de los actores involucrados en las funcionalidades del sistema, así como el nivel de esfuerzo para desarrollarlos.

Factor de peso de los actores (UAW)

Para este cálculo se tiene en cuenta la cantidad de actores presentes en el sistema y la complejidad de cada uno de ellos.

Tipo de actor

Descripción Factor de

peso

Número de

actores

Resultado

Simple Otro sistema que interactúa con la aplicación mediante API.

1 0 0

Promedio

Otro sistema que interactúa con la aplicación mediante interfaz basada

en texto.

2 0 0

Complejo

Persona que interactúa con la GUI. 3 1 3

Total: 3Tabla 3: Factores de peso de los actores

Por lo tanto el factor de peso de los actores sin ajustar (UAW) es 3.

Factor de peso en los casos de uso sin ajustar (UUCW)

Para determinar si un caso de uso es simple, promedio o complejo se ha tenido en cuenta su nivel de seguridad, de casos relacionados, y de actores que intervienen en él.

Tipo de caso de

uso

Casos de uso Factor de peso

Número de Casos de Uso

Resultado

Simple -Consultar calendario 8 8 64

electoral-consultar jurado

-consultar candidato-consultar urna-consultar mesa

-consultar escrutador-consultar claveros

-consultar tarjetón electoralPromedio -Registrar jurado

-Registrar escrutador-Registrar candidato

-Registrar Mesa-Registrar Urna

-Registrar Tarjetón-Registrar claveros

14 7 98

Complejo -Iniciar Sesión(seguridad crítica)

Crear calendario Electoral

10 2 20

Total 17 216Tabla 4: Factores de peso para los casos de uso

Con estos datos podemos determinar el factor de peso de los casos de uso sin ajustar (UUCW) que es igual a 216.

Puntos de casos de uso sin ajustar (UUCP)

UUCP = UAW + UUCW

UUCP = 3 + 216

UUCP = 219

Factor de complejidad técnica

Número de factor

Descripción Peso

Valor Factor

T1 Sistema distribuido 2 1 2T2 Tiempo de respuesta 1 3 3T3 Eficiencia por el usuario 1 4 4T4 Proceso interno complejo 1 2 2T5 Reusabilidad 1 2 2T6 Facilidad de instalación 0.5 1 0.5T7 Facilidad de uso 0.5 5 2.5T8 Portabilidad 2 3 6T9 Facilidad de cambio 1 3 3

T10 Concurrencia 1 2 2T11 Objetivos especiales de seguridad 1 4 4T12 Acceso directo a terceras partes 1 1 1T13 Facilidades especiales de entrenamiento a

usuarios finales1 1 1

Factor Total: 33Tabla 5: Factor de complejidad técnica

Con estos datos calculamos el factor de complejidad técnica:

TCF = 0.6 + 0.01 * ∑ (Pesoi x Valor asignado)

TCF = 0.6 + 0.01 * 33

TCF = 0.93

Factor Ambiente

Número del factor

Descripción Peso

Valor Factor

E1 Familiaridad con el modelo del proyecto usado

1.5 3 4.5

E2 Experiencia en la aplicación 0.5 3 1.5E3 Experiencia OO 1 4 4E4 Capacidad del analista líder 0.5 4 2E5 Motivación 1 4 4E6 Estabilidad de los requerimientos 2 4 8E8 Dificultad en lenguaje de programación -1 3 -3Total 21

Tabla 6: Factor Ambiente

El factor ambiente se calcula mediante la siguiente ecuación:

EF = 1.4 – 0.03 * ∑ (Pesoi x Valor asignado)

EF = 1.4 – 0.03 * 21

EF = 0.77

Puntos de casos de uso ajustados

UCP = UUCP * TCF * EF

UCP = 135 * 0.93 * 0.77

UCP = 96.6735

Cálculo del esfuerzo

Tomando por defecto un factor de conversión de 19 horas/hombre

E = UCP * CF

E = 96.6735 * 19

E = 1835.79 horas/hombre

Distribución real del esfuerzo

Se debe tener en cuenta que éste método proporciona una estimación del esfuerzo en horas-hombre contemplando sólo el desarrollo de la funcionalidad especificada en los casos de uso.

Para la obtención de una estimación más exacta de la duración del proyecto, se hace necesario agregar a la estimación del esfuerzo obtenida por los Puntos de Casos de Uso, las estimaciones de esfuerzo de las restantes actividades que se llevaron a cabo durante el desarrollo del software; así se la distribución del esfuerzo entre dichas actividades está dada por la siguiente aproximación (esta aproximación está basada en el calendario del proyecto).

ACTIVIDAD PORCENTAJEANÁLISIS 25%DISEÑO 25%PROGRAMACIÓN 20%PRUEBAS 15%MANTENIMIENTO 15%Tabla 7: Distribución del esfuerzo

Con este criterio y tomando como entrada la estimación de tiempo calculada a partir de los Puntos de Casos de Uso, se pueden calcular las demás estimaciones para obtener la duración total del proyecto de la siguiente manera.

ACTIVIDAD PORCENTAJEANÁLISIS 2416.8375DISEÑO 2416.8375PROGRAMACIÓN 1933.47PRUEBAS 1450.1025MANTENIMIENTO 1450.1025TOTAL: 9667.35

Tabla 8: Distribución real del esfuerzo

La distribución real del esfuerzo es entonces de 9667.35 horas/hombre.

Tiempo de desarrollo

TDesarrollo = Esfuerzo Real / Cantidad de personal

TDesarrollo = 9667.35 / 4

TDesarrollo = 2417 horas

Considerando que se trabajan 8 horas diarias

TDesarrollo = 2417/8

TDesarrollo = 302 días aproximadamente

MÉTRICAS DE HALSTEAD (PARA CÓDIGO FUENTE)

Maurice Halstead propuso las primeras leyes analíticas para el software de computadora, usando el siguiente conjunto de medidas:

● n1 = Número de operadores distintos que aparecen en un programa ● n2 = Número de operandos distintos que aparecen en un programa ● N1 = Número total de ocurrencias de un operador ● N2 = Número total de ocurrencias del operando

Para proceder con la aplicación del a métrica primero es necesario aclarar algunos conceptos:

● Operando: Abarcan todas las variables y constantes del programa, son aquellos identificadores que no son palabras reservadas, las constantes numéricas, los identificadores de tipos, los caracteres y strings constantes.

● Operadores: Incluyen todo el flujo de constructos de control, condicionales y operaciones matemáticas. Palabras reservadas (if, do, while, class, etc), los calificadores, palabras reservadas y operadores en expresiones.

Halstead usa estas medidas primitivas para desarrollar: expresiones para la longitud de programa global, volumen mínimo potencial para un algoritmo, volumen real (número de bits requeridos para especificar un programa), nivel del programa (una medida de complejidad del software), nivel del lenguaje (una constante para un lenguaje determinado) y otras características, como esfuerzo de desarrollo, tiempo de desarrollo e incluso el número proyectado de fallas en el software.

Obtención de Datos:

● n1=40● n2=86● N1=1169● N2=3613

Aplicando la métrica:

La longitud del proyecto puede estimarse como:

N = 𝑛1 𝑙𝑜𝑔2 𝑛1 + 𝑛2 𝑙𝑜𝑔2 𝑛2 N = 40𝑙𝑜𝑔2 40 + 86𝑙𝑜𝑔2 86

N = 765.535

El volumen del programa puede estimarse como:

V = 𝑁 𝑙𝑜𝑔2 (𝑛1 + 𝑛2)

V = 765.535 𝑙𝑜𝑔2 (40+86)

V = 5341.351

Este valor representa el volumen de información en bits que se requiere para especificar el programa.

Existe también una razón de volumen L que representa la forma más compacta del programa al volumen del programa real. (L debe ser menor que 1)

𝐿 = 2/𝑛1 𝑥 𝑛2/𝑁2

𝐿 = 2/40 𝑥 86/3613

𝐿 = 43/36130

Este valor es llamado por Halstead el “nivel del programa”.

Es posible también calcular el nivel de dificultad del sistema de la siguiente manera:

𝐷 = 𝑛1/2 𝑥 𝑁2/𝑛2

𝐷 = 40/2 𝑥 3613/86

𝐷 = 36130/43

Siendo inversamente proporcional al nivel del programa.

El esfuerzo de la implementación puede calcularse como el volumen por el nivel de dificultad, es decir:

𝐸 = 5341.351 𝑥 36130/43 = 4487977.015

Y por último el tiempo de Entendimiento de la aplicación:

𝑇 = 𝐸/18

𝑇 = 4487977.015/18

𝑇 = 249332.056