Sergio Andrés Díaz Hernandez

UNIVERSIDAD POPULAR DEL CESAR
Aplicación web para la gestión académica de la Institución

Educativa Joaquín Ochoa Maestre
APLICACIÓN WEB PARA LA GESTIÓN ACADEMICA DE LA INSTITUCION EDUCATIVA

JOAQUIN OCHOA MAESTRE
Presentado por:
SERGIO ANDRÉS DÍAZ HERNÁNDEZ
JURGEN HASSLER CORDOBA DE LA CRUZ
Asignatura:
INGENIERIA DE SOFTWARE II
Ingeniera:
Maribel Romero
FACULTAD DE INGENIERIA Y TECNOLOGIAS
VALLEDUPAR-CESAR
2019
1
CONTENIDO
1. Introducción
2. Nivel de prueba
2.1. Objetivos
2.2. Propósito
2.3. Alcance
2.4. Técnicas y tipos de pruebas
3. Diseño de pruebas
3.1. Pruebas unitarias
3.1.1. Pruebas de caga negra
3.1.1.1. Especificación de particiones de equivalencias
3.1.1.2. Diseño de casos de pruebas
3.1.1.3. Casos de prueba de valores limites
3.1.2. Pruebas de caja blanca
3.1.2.1. Complejidad ciclomatica de McCabe
3.1.2.2. Diseños de casos de prueba
3.2. Pruebas de integración
3.2.1. Técnicas de pruebas incrementales
3.2.1.1. Prueba incremental ascendente
3.2.1.2. Prueba incremental descendente
3.2.1.3. Pruebas de integración basada en hilos
3.2.1.4. Uso de la herramienta Katalon
4. Métricas del software
4.1. Introducción
4.1.1. Objetivo
2
4.1.2. Alcance
4.1.3. Tipos y herramientas de métricas
4.2. Formulación y recolección de datos
4.2.1. Medidas del tamaño del producto
4.2.2. Métricas CK Chindambe, Kemerer y Lorenz y Kidd
4.2.3. Métricas de funcionalidad
4.2.4. Herramienta utilizada para el análisis de software
4.2.5. Métricas utilizando el método GQM
5. Estimación del software
5.1. Estimación del tamaño usando el método PROBE
5.2. Estimación del tamaño usando puntos de casos de uso
5.3. Estimación de costo aplicando método COCOMO II
5.4. Utilice una herramienta para obtener resultados de COCOMO II
6. Calidad de software
7. Conclusiones
8. Bibliografía
3
PRUEBAS DEL SOFTWARE
1. INTRODUCCION
Las pruebas de software también conocidas como “testing” son los procesos que
permiten verificar y revelar la calidad de un producto software. Son utilizadas para
identificar posibles fallos de implementación, calidad, o usabilidad de un programa
de ordenador o videojuego. Básicamente es una fase en el desarrollo de software
consistente en probar las aplicaciones construidas.
Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que
permitan comprobar el grado de cumplimiento respecto de las especificaciones
iniciales del sistema.
1.1 Objetivos
La prueba de software es un elemento crítico para la garantía del correcto

funcionamiento del software. Entre sus objetivos están:
Objetivo General
Encontrar el mayor número de fallos en el producto software en la menor cantidad

de tiempo.
Objetivos Específicos
• Comprobar si el producto software hace lo que debe hacer, es decir, si los

resultados son correctos.
• Detectar defectos en el software.
• Identificar y asegurar que los defectos encontrados se han corregido antes

de entregar el software al cliente.
 Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes

clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.
4
1.2 Propósito
El propósito del plan de pruebas es proveer la información necesaria para planear y

controlar los esfuerzos de pruebas de un proyecto o iteración específicos. Describe
el enfoque para probar el software y es el plan general generado y utilizado por
administradores para dirigir el esfuerzo de pruebas.
1.3 Alcance
Se probará cada uno de los módulos (Alumnos, Profesores, Materias, entre otros) y
sus funciones más importantes a través de pruebas unitarias y de integración.
5
1.4 Estrategias de pruebas
1.4.1 Pruebas Unitarias
Objetivo de la prueba: Comprobar que cada uno de los

módulos está correctamente codificado.
Estrategia: Probar cada una de los módulos usando la
técnica del testeo.
Herramienta requerida: Katalon Studio
Responsables Jurgen Hassler Córdoba
Criterios de evaluación: Cada uno de los módulos a probar deben

estar terminados
Observaciones: Ninguna
Entregable Documento
1.4.2 Pruebas de Integración
Objetivo de la prueba: Comprobar si un módulo puede tener

un efecto adverso o inadvertido sobre
otro módulo, es decir probar
conjuntamente el funcionamiento de los
módulos
Estrategia: Probar cada uno de los módulos mediante
la integración.
Herramienta requerida: Word
Responsables Sergio Andrés Díaz Hernández
Criterios de evaluación: Exitosa
Observaciones: Ninguna
6
1.4.3 Pruebas de aceptación
Objetivo de la prueba: Validar conjuntamente con el cliente,

que el software cumple con todos los
requisitos previamente estipulados.
Estrategia: Plantear diferentes métodos y estrategias
para lograr la aceptación del cliente hacia
el producto a entregar
Herramienta requerida: Software finalizado
Responsables Sergio Andrés Díaz Hernández
Criterios de evaluación: Mostrar personalmente el funcionamiento

del software al cliente
Observaciones: De acuerdo a las apreciaciones del cliente
hacia el software se tomarán lo correctivos
necesarios de ser necesario.
7
2. DISEÑO DE PRUEBAS
Pruebas Unitarias
Las pruebas unitarias tienen como objetivo verificar la funcionalidad y

estructura de cada componente individualmente del sistema una vez que ha
sido codificado. En esta Prueba se debe:
 Verificar que los módulos del sistema estén libres de errores.
 Que todos los caminos lógicos principales deben ejecutarse correctamente
en cada módulo de la aplicación.
 Todas las transacciones deben ser probados.
 Todos los tipos de registro de entrada válidos deben ser procesados
 Todos los tipos de registro de entrada inválidos deben ser procesados
correctamente
 Todas las salidas válidas son procesadas.
Pruebas de Caja Negra
Estas pruebas se basan en la especificación del programa o componente a

ser probado para elaborar los casos de prueba. El componente se ve como
una “Caja Negra” cuyo comportamiento sólo puede ser determinado
estudiando sus entradas y las salidas obtenidas a partir de ellas.
8
2.2 PRUEBAS UNITARIAS
2.2.1 Especificación de particiones de equivalencia
Clase Alumnos
Condición de Entrada Clases Validas Clases Invalidas
Código estudiante. 1)codigo≤9999999999 3)código >9999999999

Numero de máximo 4)No es numero
10 dígitos. 5) Es Null
Nombres 6)Nombres≤20 caracteres 8)Nombres > 20 caracteres
Cadena de caracteres 9) Es Numero
de mínimo 3 y 10) Es Null
máximo 20. (a-z y A-
Z).
Apellidos 11) Apellidos≤20 caracteres 13) Apellidos > 20
Cadena de caracteres caracteres
de mínimo 3 y 14)Es numero
máximo 20. (a-z y A- 15) Es Null
Z).
Correo Electrónico 16) Correo≤40 caracteres 18) Correo > 40 valores
Alfanumérico máximo 19) Debe contener @ entre la cadena de 19) Es Null
40 caracteres. caracteres
Usuario 20) usuario<=35 caracteres 22) usuario> 35 valores
Alfanumérico de 23) Es Null
máximo 25 caracteres
Password 24) password<=20 caracteres 26) usuario> 20 valores
máximo 20 caracteres
9
Clase Cursos Commented [U1]: No debería tener un campo tipo nombre????
Codigo 1)codigo≤99999 2)código>99999

Numero de máximo 5 3)Es null
digitos 4)No es numero
ncurso 5) ncurso≤99999 6) ncurso>99999

Alfanumerico de máximo 7) No es numero
Clase Calificaciones
Nota _1 5)0.0≤Nota_1≤5.0 6)Nota_1<0.0

Numero decimal de máximo 7)Nota_1>5.0
1 digito después del punto 8)No es numero
que empiece por 0 y sea 9) Es Null Commented [U2]: Debe ser un campo decimal
igual o menor que 5.0
Nota_2 10)0≤Nota_2≤5.0 11)Nota_2<0.0
que empiece por 0 y sea 14) Es Null
Nota_3 15)0≤Nota_3≤5.0 16)Nota_3<0.0
que empiece por 0 y sea 19) Es Null
10
Clase Profesores
Condición de Clases Validas Clases Invalidas

Entrada
Código 1) codigo≤9999999999 3)codigo >9999999999
Numero de máximo 4)No es numero
Nombres 6)Nombres≤25 caracteres 8)Nombres > 25
Cadena de caracteres
caracteres máximo 9) Es Numero
20. (a-z y A-Z). 10) Es Null
Apellidos 11)Apellidos≤25 caracteres 13) Apellidos > 25
Cadena de caracteres
caracteres máximo 14)Es numero
20. (a-z y A-Z). 15) Es Null
Correo Electrónico 17)Correo≤40 caracteres 17) Correo < 5 valores
Alfanumérico de 19) Debe contener @ entre la 18) Correo > 40 valores
máximo 40 cadena de caracteres 19) Es Null
caracteres
Usuario 20)usuario<=35 caracteres 22) usuario> 35 valores
mínimo 5 y máximo
25
Password 24)password<=20 caracteres 26) password> 20 valores
mínimo 5 y máximo
15
11
Clase Materias Commented [U3]: Debe tener un codigo

Codigo 1) codigo≤999 2)codigo >999
Numero de máximo 3 3)No es numero
dígitos. 4) Es Null
Nombre 5)Nombre≤20 caracteres 6)Nombre > 20
Cadena de caracteres de caracteres.
máximo 20. (a-z y A-Z). 7) Es Numero
8) Es Null
Clase Actividades extras
Codigo 3) Codigo >999

Numero de máximo 3 1)Codigo≤999 4) No es numero
dígitos. 5) Es Null
Nombre 6) Nombre≤20 caracteres 8)Nombre > 20
Cadena de caracteres caracteres
máximo 20. (a-z y A-Z). 10) Es Null
11)Es número.
Descripción 11)Descripción<=200 caracteres 7)Descripción>200
Valor alfanumérico de caracteres
máximo 40 caracteres.
Fecha 12) aaaa/mm/dd 13) No es fecha.

Campo tipo fecha
12
2.2.1.1 Diseño casos de pruebas
Descripción de Casos de Prueba
Caso: Caso de prueba para registrar un estudiante.
Instrucciones de Prueba
 Iniciar sesión como administrador
 El estudiante no se encuentre registrado.
Escenarios de prueba Respuesta esperada Coincide
de la aplicación (Si/No)
Campo Valor Tipo
escenario
1065819238 Correcto Registro Guardado Si
Numero 10656266901111 Incorrecto Teclas inhabilitadas Si

Identidad
"identidad" Incorrecto Teclas inhabilitadas Si
Llenar todos los Si

"" Incorrecto
campos
"Andrés Jesús" Correcto Registro Guardado Si
Nombres "Andrés Jesús

Tercero…25" Incorrecto
Teclas inhabilitadas Si
12345 Incorrecto
Llenar todos los Si
"" Incorrecto
campos
"Manjarrez López" Correcto Registro Guardado Si
Apellidos "Manjarrez López

García Perea…26"
Incorrecto Teclas inhabilitadas Si
1 Incorrecto
13
Llenar todos los Si

"" Incorrecto campos
"davidfuente@gma
il.com " Correcto Registro Guardado Si
Correo "anjo"
Electrónico Incorrecto Debe ser un correo Si
"nosemeolvidanun
ca@hotmail.com…4 Incorrecto
0”
Llenar todos los Si
Incorrecto
campos
""
" sandresdiaz“ Correcto Registro Guardado Si
Usuario "Sergio andres…26" Incorrecto El máximo de Si

caracteres es 25.
"" Si
Incorrecto Llenar todos los
Si
campos
Password “cualquiercontra” Correcto Registro guardado Si
“asdkasdhlsdhj…26 Incorrecto El máximo de Si

” caracteres es 25.

Si
“” campos
Observaciones
Los valores limites fueron hallados directamente dentro de la tabla de los casos de
pruebas.
14
Caso: Caso de prueba para registrar un docente.
 Iniciar sesión como administrador
 El estudiante no se encuentre registrado.
Escenarios de prueba Respuesta esperada Coincide
de la aplicación (Si/No)
Campo Valor Tipo
escenario
1065819238 Correcto Registro Guardado Si
Numero 10656266901111 Incorrecto Teclas inhabilitadas Si

Identidad
"identidad" Incorrecto Teclas inhabilitadas Si
Llenar todos los Si

"" Incorrecto
campos
"Andrés Davis" Correcto Registro Guardado Si
Nombres "Andrés
JesúsTercero…26" Incorrecto
12345 Incorrecto
Llenar todos los Si
"" Incorrecto
campos
"Manjarrez López" Correcto Registro Guardado Si
Apellidos "Manjarrez López

García Perea…30"
Incorrecto Teclas inhabilitadas Si
1 Incorrecto
Llenar todos los Si
"" Incorrecto
15
campos
"anjomalo17@gma
il.com " Correcto Registro Guardado Si
Correo "anjo"
Electrónico Incorrecto Debe ser un correo Si
"nosemeolvidanun
ca@hotmail.com…4 Incorrecto
0”
Llenar todos los Si
Incorrecto
campos
""
" sandresdiaz “ Correcto Registro Guardado Si
Usuario "Sergio andres…26" Incorrecto El máximo de Si

caracteres es 25.
"" Si
Si
campos
Password “cualquiercontra” Correcto Registro guardado Si
“asdkasdhlsdhj…26 Incorrecto El máximo de Si

” caracteres es 25.

Si
“” campos
Observaciones
pruebas.
16
Caso: Caso de prueba para registrar un curso. Commented [U4]: revisar
 Estar registrado como administrador
 Registrar un curso no existente.
Escenarios de prueba Respuesta esperada de la Coincide
aplicación (Si/No)
Campo Valor Tipo
escenario
"6-04" Correcto Registro guardado Si
"7 -03" Correcto Registro guardado Si

Nombre curso
"8-01" Correcto Registro guardado Si
Llenar todos los campos Si

"" Incorrecto
Observaciones
pruebas.
17
Caso: Caso de prueba para registrar asignatura. Commented [U5]: revisar
 Registrar una asignatura inexistente.
aplicación (Si/No)
Campo Valor Tipo
escenario
"Biologí Correcto Datos guardados Si

a"
Incorrecto El máximo de letras es de 20 Si
Nombre "Biologí
Asignatura aEsjs…2
5" Incorrecto
"123" Incorrecto
""
Observaciones
pruebas.
18
Caso: Caso de prueba para registrar actividades extras.
 Registrar una actividad inexistente.
aplicación (Si/No)
Campo Valor Tipo
escenario
"Reunión Correcto Datos registrados Si

de padres"
Nombre_Activ "Natucien Incorrecto

idad cia ...36” El máximo de valores es 35 Si
"123" Incorrecto
"" Incorrecto
Descripción “Se hará Correcto Registro guardado Si

algo
important
e el… “
“Reunión
de Incorrecto
El máximo de valores es 200 Si
padres…20
1” Incorrecto
“ ”
Observaciones
pruebas.
19
Caso: Caso de prueba para registrar notas. Commented [U6]: revisar
 Estar registrado como docente.
 Asignar notas a un estudiante registrado.
 Asignar notas a un estudiante sin registros
aplicación (Si/No)
Campo Valor Tipo
escenario
2.0 Correcto Datos registrados Si

Nota _3
"nota3" Incorrecto Teclas inhabilitadas Si
"" Incorrecto Llenar todos los campos Si

Nota _2
"nota2" Incorrecto Teclas inhabilitadas Si

Nota _1
"nota" Incorrecto Teclas inhabilitadas Si
20
2.1.1.2 Casos de prueba valores límites
REGISTRAR NOTA
Campo Valor Condición a evaluar
1.0 =
Nota _1 0 < Commented [U7]: debe ser un numero decimal
5.0 =
6.0 >
1.0 =
Nota_2 0 <
5.0 =
6.0 >
1.0 =
Nota_3 0 <
5.0 =
6.0 >
REGISTRAR ASIGNATURA
"física" =
Nombre Asignatura "Informática y
tecnologías…20" <
"Informáticas y
tecnologías…21" >
REGISTRAR CURSO
1000 =
Codigo_Curso 999 <
10000 >
21
REGISTRAR ALUMNO
99999 <
Código 9999999999 =
10000000000 >
““ <
Nombres "Carlos Andrés Martin..25" =
"María Esther Etelvina…27" >
Apellidos "" <

"Manjarrez López Daza" =
"Manjarrez López Cotes" >
"anibaljosemanjarrezlopez@ =
Usuario unicesar.edu.co"
““ <
“asdnajsdnhkasdjkasjkd…36” >
Contraseña ““ <
“estaesmicontra1” =
“estaesmicontra12” >
"a@.co" =
Correo Electrónico "a@.c" <
unicesar.edu.co"
"anibaljosemanjarrezlopez@ >
unicesar.edu.com"
22
REGISTRAR DOCENTE
1000001 =
Numero Identidad 99999 <
9999999999 =
10000000000 >
"" <
Nombres "Carlos Andrés Martin…25" =
"María Esther Etelvina… 26" >
Apellidos "" <

"Manjarrez López Daza" =
"Manjarrez López Cotes" >
Usuario unicesar.edu.co"
““ <
“asdnajsdnhkasdjkasjkd…36” >
Contraseña “” <
“estaesmicontra1…20” =
“estaesmicontra12…22” >
"" <
Correo Electrónico "anibaljosemanjarrezlopez@ =
unicesar.edu.co"
"anibaljosemanjarrezlopez@ >
unicesar.edu.com"
23
2.2.2 Pruebas de Caja Blanca
24
25
Técnica de la Complejidad ciclomatica.
Clase Asignatura
Método: guardarAsignatura ()
Complejidad Ciclo matica

Formula Resultado
V(g)= a-n +2 v(g)= 17-14+2=5
Caminos
v(g)=c+1 v(g)=4+1=5 Caminos
v(g)=r v(g)= 5 Caminos
N Caminos
1 1-2-3-4-5-13-14
2 1-2-6-7-12-13-14
3 1-2-6-7-12-13-14
4 1-2-6-8-9-11-12-13-14
5 1-2-6-8-10-11-12-13-14
Grafo
26
Metodo: ListarAsignatura ()

Formula Resultado N Caminos
V(g)= a-n +2 v(g)= 1-2+2=1 1 1-2
Caminos
Grafo
27
Metodo: eliminarAsignatura () Commented [U8]: como mínimo debe haber una búsqueda que
indique una decisión

Formula Resultado N Caminos
V(g)= a-n +2 v(g)= 1-2+2=1 1 1-2
Caminos
Grafo
28
Metodo: Listar Docentes()
Grafo
Formula Resultado
V(g)= a-n +2 v(g)= 5-5+2=2
1 Caminos
N Caminos
1 1-2-4-5
5 2 1-2-3-4-5
29
Metodo: Eliminar ()

Formula Resultado
V(g)= a-n +2 v(g)= 1-2+2=1
Caminos N Caminos
v(g)=c+1 v(g)=0+1=1 Caminos 1 1-2
Grafo
30
Método: guardarDocente ()
Complejidad Ciclo matica N Caminos

Formula Resultado 1 1-2-3-4-5-13-14
V(g)= a-n +2 v(g)= 17-14+2=5 2 1-2-6-7-12-13-14
Caminos 3 1-2-6-7-12-13-14
v(g)=c+1 v(g)=4+1=5 Caminos 4 1-2-6-8-9-11-12-13-14
5 1-2-6-8-10-11-12-13-14
31
Grafo
32
2.2.3 Ejecución de las pruebas
Metodo Login ()
Método RegistrarAlumno ()
33
Método registrar asignatura
Método registrar curso
34
2.2.4 Evaluación de las pruebas
PRODUCTO CASO DE PUREBA RESULTADO SEGUIMIENTO CONCLUSION

Interfaz Registrar OK No hay fallos al Se registró
asignatura registrar una correctamente
asignatura la asignatura
Interfaz Registrar nota OK No hay fallos al Se registró
registrar una correctamente
nota la nota
Interfaz Registrar curso OK No hay fallos al Se registró
registrar un correctamente
curso el curso
Interfaz Registrar alumno OK No hay fallos al Se registró
registrar un correctamente
alumno el alumno
docente registrar un correctamente
docente el docente
actividades registrar una correctamente
actividad la actividad
35
2.3. PRUEBAS DE INTEGRACION
El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los

distintos módulos que componen la solución una vez que han sido probados
unitariamente con el fin de comprobar que interactúan correctamente a través de sus
interfaces internas y externas, que cubren la funcionalidad establecida y se ajustan a los
requisitos no funcionales especificados en las verificaciones correspondientes.
2.3.1 Técnicas de pruebas incrementales
36
2.3.1.1. Incremental Ascendente (Bottom-Up)
UNITARIAS: (9,11,13,15,17,19,21,22,23, 34,25,26,27,28,29,30,31,32)

INTEGRACION: (18 con 29), (18 con 30), (20 con 31), (20 con 32)
INTEGRACION: (7 con 17), (7 con 18), (8 con 19), (8 con 20), (10 con 21), (10 con 22), (12
con 23), (12 con 24), (14 con 25), (14 con 26), (16 con 27), (16 con 28)
INTEGRACION: (2 con 7), (2 con 8), (3 con 9), (3 con 10), (4 con11), (4 con 12), (5 con 13),
(5 con 14), (6 con 15) y (6 con 16)
INTEGRACION: (1 con 2), (1 con 3), (1con 4), (1con 5) y (1 con 6)
2.3.1.2. Incremental descendente (Top-Down)
 PROFUNDIDAD
(1,2,7,17,18,29,30,8,19,20,31,32,3,9,10,21,22,4,11,12,23,24,5,13,14,25,26,6,15,16,27,28
)
 ANCHURA
(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32
)
2.3.1.3 Diseño de los casos de prueba
N° Descripción Método Datos Entrada Salida esperada OK

Método que permite “admin@admin.com”
iniciar sesión como Iniciar “ADMIN” Login sucefully
1 administrador sesión OK
2 Método que permite Registrar ” filosofía” “ Asignatura
registrar asignatura asignatura registrada con OK
éxito
37
2.3.2 Pruebas basadas en hilos
Caso de Uso: Registrar Asignatura
Caso de prueba No. 1 Variable 1 Resultado Esperado

(Nombre)
Nombre_Asignatura “Biologia” Mensaje

Registro exitoso
Nombre_Asignatura “” Mensaje
Llenar todos los campos.
Nombre_Asignaturas “ 1111” Mensaje

Datos inválidos.
Caso de Uso: Registrar Curso
Caso de prueba No. 1 Variable Resultado Esperado

1(ncurso)
ncurso “8-01” Mensaje

Registro exitoso
ncurso “” Mensaje
Llenar todos los campos.
ncurso “octavo ” Mensaje

Datos inválidos.
38
Caso de Uso: Registrar Actividad
Caso de prueba Variable 1 Variable Resultado

No. 1 (Nombre_Ac 2(Descripci Esperado
tivdad) on)
Nombre_Asignatura, “Reunion” “El dia de Mensaje

Descripción mañana Registro exitoso
habrá
reunión de
padres de
familia”
Nombre_Asignatura, “” “” Mensaje
Descripción Llenar todos los
campos.
Nombre_Asignatura, “Entrega de “” Mensaje
Descripcion notas” Llenar todos los
campos.
Nombre_Asignatura, Mensaje
Descripcion “11111” “” Datos Inválidos.
39
2.4 PRUEBAS DE ACEPTACION
El objetivo de las pruebas de aceptación es validar que la solución desarrollada cumpla con
el funcionamiento esperado y permitir al usuario de dicho sistema determine su
aceptación, desde el punto de vista de su funcionalidad y de su rendimiento. Estas pruebas
son realizadas por el cliente, donde comprueba que el sistema cumple con lo definido y se
obtiene la conformidad del cliente. Esta prueba se realiza mediante el proceso de
validación de caja negra.
2.4.2 Ejecución de las pruebas
2.4.3 Evaluación de las pruebas
ANALISIS DE RESULTADOS
Participantes: Clientes Fecha:
Tipo prueba: Aceptación Área (a realizar la prueba): Interfaz
Funcionalidad: Requerimientos Líder: Sergio Díaz
textuales
Porcentaje de satisfacción obtenido: 92%
Análisis de resultados
Atributo % del % de N° de Aprobadas Reprobadas
atributo satisfacción pruebas
Facilidad de 100 89 4 4 0
uso
Comentarios:
40
3.MÉTRICAS DEL SOFTWARE
3.1 Introducción
Para el proceso de desarrollo de un proyecto de software, se deben realizar una serie de

pasos y actividades para que su ejecución sea ejecutada de una manera correcta, dentro
de estas actividades tenemos, la estimación, la planificación del programa, el análisis de
riesgos, la medición y las métricas.
Antes de comenzar con la ejecución de un proyecto de software, se deben recopilar datos,

calcular métricas y evaluarlas, estos pasos son muy importantes para que el producto que
se ejecutado de manera correcta siguiendo unos estándares mínimos.
El objetivo de la consideración de métricas de software es llevar a cabo análisis de puntos

débiles y fuertes dentro de la ejecución del proyecto, débiles como el aumento de esfuerzo
y fuertes como la calidad, reusabilidad y madurez, en los que se ven involucrados los
ingenieros de software, el uso de las métricas se está adoptando con éxito en el amplio
mercado de desarrollo de software introduciendo nuevas investigaciones y
consideraciones por pate de administradores y usuarios, en pro de la necesidad de un
enfoque más disciplinado y de la calidad.
3.1.1 Objetivos
Al aplicar las métricas de software lo que se busca es proporcionar una evaluación del
proyecto que aún se encuentra en continuo desarrollo, también observar los posibles
defectos de puedan provocar riesgos a corto y mediano plazo, permitiéndonos también
observar si el área de trabajo y las distintas tareas se ejecutaran en los tiempos estimados.
 Describir la utilidad de las métricas de software.
 Dar ejemplos de uso de diversos tipos de métricas.

 Aplicar las métricas de software para asegurar la calidad de un producto de manera
objetiva.
 Explicar la importancia de la medición en los procesos de calidad.
3.1.2 Alcance
 Modelo de medición GQM

 Modelo de medición por tamaño-longitud (LOC)
41
 Modelo de medición tamaño-funcionalidad

 Métricas CK & LK
3.1.3 Tipos y herramientas de métricas
GQM: GQM (Goal-Question-Metric) es un paradigma para desarrollar y

mantener un significativo programa de métricas, este proporciona una manera
útil para definir mediciones tanto del proceso como de los resultados de un
proyecto.
LOC: LOC es un acrónimo de “Lines of Code”. Se utiliza como métrica en diversas

situaciones, en las que se mide el número de líneas de código.
Usualmente, se utiliza la variante “KLOC”, que son miles de líneas de código.
Métricas Halstead: Las métricas de Complejidad de Halstead fueron

desarrolladas por Maurice Halstead como un medio de determinar la
complejidad cuantitativa directamente de los operadores y operandos usados
en el código fuente de un módulo.
Modelo de puntos de función (PF): Los puntos de función son un número

positivo con escala arbitraria que refleja el tamaño de la funcionalidad del
sistema (a mayor tamaño mayor número de puntos de función).
Métricas CK Chidamber y Kemerer: Son métricas orientadas a clases:
clases individuales, herencia y colaboraciones. Es uno de los conjuntos de
métricas más referenciado.
Métricas LK Lorenz y Kidd: Son métricas orientadas a los distintos métodos

y para los distintos proyectos OO.
3.2 Métricas de tamaño
3.2.1 Determine las siguientes medidas del tamaño del producto
Clase/función Métodos /módulos No. No. LOC Complejidad

Atributos Ciclomatica
listarActividades 4 11 1
Actividades guardarActividad 4 18 2
extras eliminarActividad 4 18 1
modificarActividad 4 24 1
Subtotal Área 4 métodos 16 atrib. 71 LOC 4 C.C.
42
listarAsignatura 2 11 1
guardarAsignatura 2 12 2
Asignaturas eliminarAsignatura 2 18 1
modificarAsignatura 2 23 1
Subtotal Asig. 4 métodos 8 atrib. 64 LOC 4 C.C.
listarDocente 6 19 1
guardarDocente 8 22 2
eliminarDocente 1 18 1
Docentes
ModificarDocente 8 35 1
docenteVer 8 14 1
RegistrarActividad 3 7 1
cargarCurso 2 6 1
Subtotal Doc. 7 métodos 36 atrib. 101 LOC 8 C.C.
listarEstudiantes 9 11 1
Estudiantes guardarEstudiante 9 28 2
eliminarEstudiante 1 18 1
ModificarEstudiante 9 42 1
CargarActividades 3 9 1
CargarCurso 3 9 1
Subtotal Est. 6 métodos 34 atrib. 117 LOC 7 C.C.
listarCurso 3 10 1
Cursos guardarCurso 3 10 2
eliminarCurso 1 18 1
Subtotal Cur. 3 métodos 7 atrib. 38 LOC. 4 C.C.
ListarCalificacion 5 11 1
Calificaciones
EliminarCalificacion 5 23 1
RegistrarCalificacion 5 19 2
Subtotal Nota 3 métodos 15 atrib. 53 LOC. 4 C.C.
Total N° de Total N° de métodos Total atrib Total LOC= Total C.C = 31
clases = 6 = 27 = 116 444
¿Cuál es la parte más compleja?
De acuerdo a los resultados obtenidos el modulo con mayor complejidad ciclomatica es el

de docentes.
43
¿Cuál tiene mayor tamaño?
Teniendo en cuenta la cantidad de LOC, el mayor tamaño lo tiene el modulo de

estudiantes.:
Diseñar 5 métricas, indique las medidas y el uso de cada métrica.
Nombre Porcentaje LOC por clase

Proposito Determinar el porcentaje de LoC por clase de cada módulo.
Metodo de Contar el número de LoC por clase y comparar con el número total
aplicación de LoC, luego multiplicarlo x 100.
𝑇𝑜𝑡𝑎𝑙 𝐿𝑂𝐶 𝑑𝑒 𝑙𝑎 𝑐𝑙𝑎𝑠𝑒
Medicion, * 100
𝑇𝑜𝑡𝑎𝑙 𝐿𝑂𝐶
formula
Interepretacion 0<=x<=1 Entre más se acerque a 1 mejor
Tipo escala Count, Ratio
Tipo medida X= Ratio
A= count B= count
Fuente de A= Lineas de código de la clase origen
medicion B= Total líneas de códigos de todas las clases
ISO/IEC 12207 Aseguramiento de la calidad.
SLCP
Audiencia Desarrolladores.
Nombre Porcentaje de CC por clase

Proposito Determinar el porcentaje de la complejidad ciclomatica por clase de
cada módulo.
Metodo de Contar el número de CC de la clase y comparar con el número total
aplicación de CC, luego multiplicarlo x 100.
𝑇𝑜𝑡𝑎𝑙 𝐶𝐶 𝑑𝑒 𝑙𝑎 𝑐𝑙𝑎𝑠𝑒
Medicion, * 100
𝑇𝑜𝑡𝑎𝑙 𝐶𝐶
formula
Tipo escala Count, Count
Tipo medida X= Count
A= count B= count
Fuente de A= Complejidad ciclomatica de la clase origen
medicion B= Total de complejidad ciclomatica de todas las clases
SLCP
44
Nombre Porcentaje de atributos por clase

Proposito Determinar el porcentaje de los atributos por clase de cada módulo.
Metodo de Contar el número de atributos de la clase y comparar con el número
aplicación total de atributos, luego multiplicarlo x 100.
𝑇𝑜𝑡𝑎𝑙 𝑎𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠 𝑑𝑒 𝑙𝑎 𝑐𝑙𝑎𝑠𝑒
Medicion, * 100
𝑇𝑜𝑡𝑎𝑙 𝑎𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠
formula
A= count B= count
Fuente de A= Atributos de la clase origen
medicion B= Total de atributos de todas las clases
SLCP
Nombre Porcentaje de atributos por método

Proposito Determinar el porcentaje de los atributos por metodo de cada
módulo.
Metodo de Contar el número de atributos del metodo y comparar con el número
aplicación total de atributos de la clase, luego multiplicarlo x 100.
𝑇𝑜𝑡𝑎𝑙 𝑎𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠 𝑑𝑒𝑙 𝑚𝑒𝑡𝑜𝑑𝑜
Medicion, * 100
𝑇𝑜𝑡𝑎𝑙 𝑎𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠 𝑐ñ𝑎𝑠𝑒
formula
A= count B= count
Fuente de A= Atributos del metodo
medicion B= Total de atributos de la clase
SLCP
45
Nombre Porcentaje de métodos por clase

Proposito Determinar el porcentaje de métodos por clase de cada módulo.
Metodo de Contar el número de métodos de la clase y comparar con el
aplicación número total de métodos de todos los módulos, luego multiplicarlo
x 100.
𝑇𝑜𝑡𝑎𝑙 𝑀é𝑡𝑜𝑑𝑜𝑠 𝑑𝑒 𝑙𝑎 𝑐𝑙𝑎𝑠𝑒
Medicion, * 100
𝑇𝑜𝑡𝑎𝑙 𝑀é𝑡𝑜𝑑𝑜𝑠
formula
A= count B= count
Fuente de A= Metodo de la clase origen
medicion B= Total de metodos de todas las clases
SLCP
 Realice un análisis del tamaño del producto teniendo en cuenta las diferentes
medidas (LOC, Complejidad)
- La clase que menos LOC tiene, es cursos.

- El promedio de la complejidad ciclomatica es 5
- La clase que más LOC tiene es la de Estudiantes
- El promedio de líneas de código es 74
- El número de líneas de código, la complejidad ciclomatica de la clase docente
es mayor a la de la clase estudiante
- La complejidad ciclomatica de la clase Actividades extras es igual a la de la clase
Asignaturas.
46
3.2.2 Encuentre las siguientes medidas, interprételas y realice un análisis
Clase/ Métodos Profundi No. Acopla No No No No

módulos pondera dad del de miento atributo Atributos Método método
dos por árbol de hijos entre s públicos s s
clase herencia NOC clases privado privado público
WMC DIT CBO s s s
Áctividades 4 0 5 0 3 1 0 4
Asignaturas 5 0 5 0 3 1 0 4
Docentes 7 0 4 0 7 1 0 7
Estudiantes 7 0 5 0 7 1 0 6
Cursos 3 0 5 0 2 1 0 3
Notas 2 0 4 0 4 1 0 3
Totales 28 0 28 0 26 6 0 27
Métricas de ciclo de vida (MODELO DE DISEÑO) Commented [U9]: falto, completar

𝑁° 𝑑𝑒 ℎ𝑖𝑗𝑜𝑠 𝑝𝑜𝑟 𝑐𝑙𝑎𝑠𝑒
Porcentaje de hijos por clase = 𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 ℎ𝑖𝑗𝑜𝑠
* 100
𝑁° 𝑑𝑒 𝑎𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠 𝑝𝑡𝑖𝑣𝑎𝑑𝑜𝑠 𝑝𝑜𝑟 𝑐𝑙𝑎𝑠𝑒

Porcentaje de atributos privados por clase = 𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 𝑎𝑡𝑟𝑖𝑏𝑢𝑡𝑜𝑠 𝑝𝑟𝑖𝑣𝑎𝑑𝑜𝑠
* 100
𝑁° 𝑑𝑒 𝑚𝑒𝑡𝑜𝑑𝑜𝑠 𝑝𝑢𝑏𝑙𝑖𝑐𝑜𝑠 𝑝𝑜𝑟 𝑐𝑙𝑎𝑠𝑒

Porcentaje de métodos públicos por clase = * 100
𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 𝑚𝑒𝑡𝑜𝑑𝑜𝑠 𝑝𝑢𝑏𝑙𝑐𝑜𝑠
𝑁° 𝑑𝑒 𝑚𝑒𝑡𝑜𝑑𝑜𝑠 𝑝𝑜𝑛𝑑𝑒𝑟𝑎𝑑𝑜𝑠 𝑝𝑜𝑟 𝑐𝑙𝑎𝑠𝑒

Porcentaje de métodos ponderados por clase = * 100
𝑇𝑜𝑡𝑎𝑙 𝑑𝑒 𝑚𝑒𝑡𝑜𝑑𝑜𝑠 𝑝𝑜𝑛𝑑𝑒𝑟𝑎𝑑𝑜𝑠 𝑝𝑜𝑟 𝑐𝑙𝑎𝑠𝑒
47
2.2.3 Métricas de funcionalidad
Tome el documento de requerimientos funcionales, requerimientos no funcionales, el

diagrama de clases, las interfaces de entradas y salidas, determine:
Requerimientos Entradas
Registrar El sistema debe permitir registrar una actividad extra, para informar
Actividad acerca de eventos en la institución. (reunión de padres de familia,
eventos en específico)
Modificar El sistema debe permitir modificar una actividad
Actividad
Eliminar El sistema debe permitir eliminar una actividad
Actividad
Registrar El sistema deberá permitir registrar una asignatura al sistema
asignatura (geometría, ingles)
Modificar El sistema debe permitir modificar una asignatura
asignatura
Eliminar El sistema debe permitir eliminar una asignatura
Asignatura
Registrar curso El sistema debe permitir registrar un curso al sistema (6,7,8,9)
Eliminar curso El sistema debe permitir eliminar un curso
Registrar El sistema deberá permitir registrar un estudiante (andrés, Gustavo,
estudiante Carlos)
Eliminar El sistema deberá permitir eliminar un estudiante
estudiante
Modificar El sistema deberá permitir modificar los datos del estudiante
estudiante
Registrar docente El sistema deberá permitir al usuario registrar docentes al sistema
Eliminar docente El sistema debe permitir eliminar docentes del sistema
Modificar El sistema debe permitir modificar los datos de un docente
docente previamente registrado en el sistema
Registrar nota El sistema debe permitir registrar notas al sistema
Modificar nota El sistema debe permitir modificar las notas de un estudiante
registrado en el sistema
Asignar El sistema debe permitir asignar estudiantes a los respectivos
estudiantes a cursos disponibles
cursos
Agregar El sistema debe permitir asociar asignaturas a los cursos
asignaturas a
cursos
48
Asignar El sistema debe permitir definir las asignaturas a los docentes

asignaturas a registrados en el sistema
docentes
Requerimientos Consultas
Generar listado El sistema debe generar un documento en formato PDF con el
de los docentes listado total de los docentes registrados en el sistema.
Generar informe El sistema debe permitir generar un documento en formato PDF con
del docente la información personal del docente
Requerimientos Salidas
Visualizar el El sistema debe mostrar las actividades que han sido previamente
listado de las registradas
actividades
Visualizar el El sistema debe mostrar las asignaturas que han sido previamente
listado de las registradas
asignaturas
Visualizar el El sistema debe mostrar los cursos que han sido previamente
listado de cursos registrados
Visualizar el El sistema debe mostrar los docentes que han sido previamente
listado de registrados
docentes
Visualizar el El sistema debe mostrar los estudiantes que han sido previamente
listado de registrados
estudiantes
Visualizar listado El sistema debe permitir mostrar las notas de los estudiantes en el
de notas sistema.
Entidad – Archivo
Estudiantes
Docentes
Actividades
Cursos
Asignaturas
Calificaciones
49
 Calcule el punto de función sin ajustar
Parámetros de Simple Medio Complejo Total

medición
No. Entradas 19* 4 76
No. Salidas 6* 5 30
Consultas 2*3 6
Almacenamiento 6 * 10 60
Interfaces 0*7 0
Total 172
Punto de función sin ajustar (PFS) = 172
 Calcule el factor de complejidad de procesamiento, considere los requisitos no

funcionales, planteados en su proyecto
Factor de ajuste Peso

1. Comunicación de datos 3
2. Procesamiento distribuido 2
3. Objetivos de rendimiento 2
4. Configuración de uso intensivo 3
5. Tasas de transacciones rápidos 3
6. Entradas de datos Online 4
7. Amigabilidad en el diseño 4
8. Actualización de datos Online 3
9. Procesamiento complejo 2
10. Reusabilidad 4
11. Facilidad de instalación 0
12. Facilidad operacional 3
13. Multiplicidad de emplazamientos 0
14. Versatilidad 3
Total 36
Puntos de complejidad de procesamiento (PCP) = 36
 Determine el punto de función
FCP = 0,65 + (0.01 * PCP)
50
FCP = 0,65 + (0.01 * 36)

FCP = 0,65 + 0,36
FCP = 1,01
PF = PFS * FCP
PF = 172* 1,01
PF = 173,72
 Tamaño en miles de líneas de código KLOC.

Lenguaje de programación PHP = 20
(173.72 ∗20 )
KLOC = 1000
KLOC = 3.4744
2.4 Métricas de productos con atributos externos.
Determine métricas utilizando el método GQM
Garantizar la mantenibilidad del software
Asegurar la fiabilidad del software
Adaptabilidad del software en diferentes ambientes
Facilidad de aprendizaje del sistema
 Garantizar la mantenibilidad del software

Preguntas:
- ¿Con que frecuencia se presentan fallos en el sistema?

- ¿Qué tan comentando se encuentra el código?
Medidas:
- Frecuencia de fallos encontrados después de una modificación

- Densidad de comentarios
51
Métricas:
𝑛𝑢𝑚𝑒𝑟𝑜 𝑑𝑒 𝑓𝑎𝑙𝑙𝑜𝑠 𝑑𝑒𝑠𝑝𝑢𝑒𝑠 𝑑𝑒 𝑢𝑛𝑎 𝑚𝑜𝑑𝑖𝑓𝑖𝑐𝑎𝑐𝑖𝑜𝑛
- Frecuencia de fallos =
𝑛𝑢𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑓𝑎𝑙𝑙𝑜𝑠 𝑐𝑜𝑟𝑟𝑒𝑔𝑖𝑑𝑜𝑠
𝑁𝑢𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑙𝑖𝑛𝑒𝑎𝑠 𝑐𝑜𝑚𝑒𝑛𝑡𝑎𝑑𝑎𝑠

Densidad de comentarios = 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑙𝑖𝑛𝑒𝑎𝑠 𝑑𝑒 𝑐𝑜𝑑𝑖𝑔𝑜
 Asegurar la fiabilidad del software
Preguntas:
- ¿Qué tan tolerante a fallos es el software?

- ¿Qué tan eficiente es el software?
Medidas:
- Porcentaje de fallos por operación

- Porcentaje de respuesta por operación
Métricas:
𝑛𝑢𝑚𝑒𝑟𝑜 𝑑𝑒 𝑓𝑎𝑙𝑙𝑜𝑠 𝑝𝑜𝑟 𝑜𝑝𝑒𝑟𝑎𝑐𝑖𝑜𝑛
- Porcentaje de fallos =
𝑛𝑢𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑜𝑝𝑒𝑟𝑎𝑐𝑖𝑜𝑛𝑒𝑠
𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑟𝑒𝑠𝑝𝑢𝑒𝑠𝑡𝑎 𝑝𝑜𝑟 𝑜𝑝𝑒𝑟𝑎𝑐𝑖𝑜𝑛

Porcentaje de respuesta =
𝑛𝑢𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑜𝑝𝑒𝑟𝑎𝑐𝑖𝑜𝑛𝑒𝑠
 Adaptabilidad del software en diferentes ambientes
Preguntas:
- ¿Cuál es el grado de portabilidad del software?

- ¿Puede el usuario o quien mantiene el software fácilmente instalar el software
en un ambiente operacional?
Medidas:
- Grado de portabilidad
- Grado de complejidad de instalación
52
Métricas:
𝐶𝑜𝑠𝑡𝑜 𝑑𝑒 𝑝𝑜𝑟𝑡𝑎𝑟 𝑒𝑙 𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒
- GP = 1 -
𝑐𝑜𝑠𝑡𝑜 𝑑𝑒 𝑟𝑒𝑑𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑎𝑟 𝑒𝑙 𝑠𝑜𝑓𝑡𝑤𝑎𝑟𝑒
Donde si el valor obtenido es mayor a cero, se concluye que la portabilidad es

más efectiva que desarrollar nuevamente.
Basado en el sistema CASSIEL
𝐴
- Grado de complejidad de instalación = 𝐵
A = Número de casos en que el usuario es exitoso en la operación de
instalación
B = Número total de casos en que el usuario ejecuta la operación de instalación
 Facilidad de aprendizaje del sistema
Preguntas:
- ¿Cuán consistentes son los componentes de las interfaces de usuario?

- ¿Qué tan fácil de manejar es el software?
Medidas:
- Consistencia operacional en el uso

- Porcentaje de usuarios que pueden llevar a cabo tareas clave sin leer el manual
Métricas:
- X=1–A/B
X= consistencia operacional en el uso
A= Numero de funciones que el usuario encontró inaceptablemente
inconsistentes según sus expectativas.
B= Numero de funciones usadas por el usuario durante el periodo de prueba
53
3.4 Utilice una herramienta de métricas, analice las medidas que genera (Muestre el
pantallazo de la herramienta analizando su software).
La herramienta utilizada fue:
54
Análisis de los resultados Commented [U10]: falto

Commented [J11R10]:
Se comprobó que se necesita saber todas y cada una de las necesidades del cliente y por
medio de las métricas se evalúa el esfuerzo por cumplir con satisfacer esa necesidad. Las
métricas que provienen de estas medidas proporcionan una indicación de la efectividad de
las actividades de control y de la garantía de calidad, de manera tal que las estrategias
lleguen al punto de generar resultados positivos en el producto que se ha desarrollado.
55
5. ESTIMACION DEL SOFTWARE
3.1 Estimación del software usando el método PROBE
CLASE ITEMS LOC LOC por

ITEM
Asignatura 4 64 16
Curso 3 38 12.6
Estudiante 6 101 16.8
Docente 7 117 16.7
Actividades extra 4 71 17.75
Nota 3 53 17.6
3.2 Estimación del tamaño utilizando puntos de casos de uso
PASO 1. CALCULAR LOS PUNTOS DE CASOS DE USO SIN AJUSTAR (UUCP)
PESOS DE LOS CASOS DE USO SIN AJUSTAR (UUCW)
Casos de uso Tipo Peso Resultado

Gestión Simple 5 5
Asignatura
Gestión Medio 10 10
Estudiantes
Gestión Curso Simple 5 5
Gestión Docente Medio 10 10
Gestión Simple 5 5
Actividades
Gestión Nota Simple 5 5
UUCW 40
56
PESO DE LOS ACTORES SIN AJUSTAR (UAW)
Actor N° de actores Peso Resultado

Administrador 1 10 10
Docente 1 5 5
Estudiante 1 5 5
UAW 20
UUCP = UUCW + UAW
UUCP = 40 + 20 = 60
PASO 2. TCF (Factor de Complejidad Técnica)
Factor Descripción Peso Impacto Factor

técnico percibido calculado
T1 Sistema distribuido 2 0 0
T2 Rendimiento o tiempo de 1 4 4
respuesta
T3 Eficiencia del usuario final 1 3 3
T4 Procesamiento interno complejo 1 2 2
T5 El código debe ser reutilizable 1 4 4
T6 Facilidad de instalación 0.5 0 0
T7 Facilidad de uso 0.5 4 2
T8 Portabilidad 2 2 4
T9 Facilidad de cambio 1 3 3
T10 Concurrencia 1 2 2
T11 Características especiales de 1 2 2
seguridad
T12 Provee acceso directo a terceras 1 1 1
partes
T13 Se requiere facilidades especiales 1 2 2
de entrenamiento a usuarios
Factor
total técnico = 29
Fórmula para calcular el TCF
TCF = 0.6 + (0.1 * Factor total técnico)
TCF = 3.5
57
PASO 3. FACTOR DE COMPLEJIDAD AMBIENTAL (ECF)
Factor Descripción Peso Impacto Factor

ambiental percibido calculado
E1 Familiaridad con el modelo de 2 3 6
proyecto utilizado
E2 Personal tiempo parcial 1 1 1
E3 Capacidad de analista líder 1 4 4
E4 Experiencia en la aplicación 1 3 3
E5 Experiencia en orientación a 1 4 4
objetos
E6 Motivación 0.5 5 2.5
E7 Dificultad del lenguaje de 0.5 3 1.5
programación
E8 Estabilidad de los requerimientos 2 3 6
Factor 28
Ambiental Total
Fórmula para calcular ECF
ECF = 1.4 + (-0.03 * Factor ambiental Total)
ECF = 1.4 + (-0.03 * 28) = 0.56
PASO 4
Calculo de UCP sin productividad
UCP = UUCP*TCF*ECF
UCP = 65*3.5*0.56
UCP = 127.4
58
3.2.1 Estime el esfuerzo con la siguiente métrica.
A B M
1.05 1.05 1.02
Esfuerzo= A*TamañoB *M
Método Tamaño Esfuerzo

LOC 444 644.9
LOC POR PF 173,72 239.73
Análisis de resultado
Se puede decir que el esfuerzo arroja un resultado mayor cuando se utiliza el método de
LOC para medir el tamaño.
3.2.2 Estime el esfuerzo considerando los tamaños con PF y UCP

PF 173,72 1737.2
UCP 60 1200
De acuerdo a la siguiente tabla:
EHP = PF * Horas x PF
[KARNER93] propone un factor de 20 horas / hombre por punto de caso de uso, resultado
del valor medio obtenido en su investigación, para la estimación temprana del esfuerzo
59
requerido para el desarrollo de un sistema de software. Por lo tanto, la cantidad total de

horas hombre estimada para un proyecto de software se calcula como:
Total horas/hombre = UCP * MR (recursos necesarios por UCP)
Total horas/hombre = UCP * 20
Total horas/hombres = 60 * 20= 1200
El resultado del esfuerzo es mayor cuando se eligió el tamaño por PF comparado con UCP.
3.2.3 Estime el esfuerzo considerando la métrica del modelo COCOMO I
Utilizando el tipo de proyecto semiacoplado y el modelo de COCOMO básico de acuerdo a

las características del proyecto.
A=3.0
B=1.12
60
Se calcula el esfuerzo con la siguiente formula:
E=a(KLOC)b
Entonces
(173.72 ∗20 ) (444 ∗20 )
KLOC = 1000
KLOC = 1000

LOC 8.88 34.621
LOC POR PF 3.4744 12.1033
El resultado del esfuerzo es mayor cuando se escoge el método de LOC por PF, en
comparación con el método LOC.
61
3.3 Estimación de costo aplicando método de COCOMO II
 Modelo de composición de aplicación
Complejidad - Peso
Tipo de objeto Simple Media Difícil Subtotal
Ventana 6X2 12
Informe 8X5 40
Componentes 10x10 100
Total OP 152
(𝑂𝑏𝑗𝑒𝑐𝑡 𝑝𝑜𝑖𝑛𝑡𝑠)𝑥 (100 − %𝑟𝑒𝑢𝑠𝑒)

NOP = 100
(152) 𝑥 (100 − 20)

NOP= 100
NOP= 121,6
Razón de productividad
Experiencia y Muy Baja Nominal Alta Muy

capacidad de los baja alta
desarrolladores
Madurez y capacidad Muy Baja Nominal Alta Muy
de ICASE baja alta
PROD 4 7 13 25 50
Esfuerzo dado en Meses-persona
PM = NPO / PROD
PM = 121,6 / 13
PM = 9.353
62
 Modelo de diseño temprano
El esfuerzo viene dado por:
A = Constante de calibración (2,45 o 2,94)
Tamaño = KLOC
B = 0.91 + 0.01 x Sumatoria de tabla de factores de escala
A = 2,94
Tamaño = 3.4744 KLOC
B = 0.91 + 0.01 x 12,65
B = 1.036
PM nominal = 9.1944
El esfuerzo ajustado será:
FA = factores de ajuste
63
Factor de ajuste = 1.05
PM ajustado = 9.194 * 1.05
PM ajustado = 9.6542
El tiempo estimado, una vez conocido el esfuerzo necesario, se obtiene de:
Siendo:
PM = esfuerzo expresado en persona-mes
C=3
64
d = 0.33 + 0.2 * [B - 1.01]
d = 0.33 + 0.2 * [1.036 - 1.01]
d = 0.3352
SCED% = es el porcentaje de comprensión/expansión del tiempo
Tdes = 17.19 * 130 / 100
Tdes = 22
El personal a tiempo completo necesario para el desarrollo (PDTC) será:
PDTC = PM / Tdes
PDTC= 9.65 / 22
PDTC= 0.438
65
Herramienta COCOMO II
En primera instancia, se da el nombre del proyecto o modulo que se va estimar.
Se especifican el número de las entradas, salidas, consultas y archivos lógicos presentes en

el proyecto y se escoge el lenguaje de programación correspondiente para los PF, como
no está PHP elegimos uno equivalente a sus PF, en este caso “FOURTH GENERATION”.
66
Cuando ya se han introducido estos datos, el programa realiza unas estimaciones.
Esfuerzo, semanas, productividad, costo, personal.
Donde cada una de las anteriores se clasifican según tres criterios:
-Optimista -Más común -Pesimista
De acuerdo a una investigación realizada se obtuvo que el salario mínimo de un

desarrollador es el siguiente:
Al convertirse a USD dólares estadounidenses da un valor de 691,976, con este dato se

puede estimar el costo del proyecto para cada uno de los 3 criterios de evaluación.
Al obtener los resultados se puede decir que en la circunstancia más probable el costo del
proyecto será de 801 dolares.
67
4. CALIDAD DEL SOFTWARE
El modelo de calidad del producto definido por la ISO/IEC 25010 se encuentra compuesto
por las ocho características de calidad que se muestran en la siguiente figura:
Tomando como medida la escala de 0 al 5 donde 0 es la calificación menos satisfactoria y

5 es la calificación más satisfactoria
1. Deficiente
2. Insuficiente
3. Aceptable
4. Sobresaliente
5. Excelente
CARACTERISTICA SUBCARATERISTICA PUNTAJE TOTAL

CARACTERISTICA
ADECUACION Completitud funcional 4
FUNCIONAL Corrección funcional. 4 12
Pertinencia funcional 4
EFICIENCIA DE Comportamiento temporal. 3
DESEMPEÑO Utilización de recursos. 4 10
Capacidad 3
COMPATIBILIDAD Coexistencia 5
Interoperabilidad 2 7
USABILIDAD Capacidad para reconocer 3
su adecuación
68
Capacidad de aprendizaje 3
Capacidad para ser usado 4
Protección contra errores de 4 18
usuario.
Estética de la interfaz de 3
usuario
Accesibilidad 1
FIABILIDAD Madurez 4 11
Disponibilidad 4
Tolerancia a fallos 2
Capacidad de recuperación 2
SEGURIDAD Confidencialidad 3
Integridad 4
No repudio 3 19
Responsabilidad. 4
Autenticidad 4
MANTENIBILIDAD Modularidad 3
Reusabilidad 3
Analizabilidad 3 16
Capacidad para ser 3
modificado
Capacidad para ser probado 4
PORTABILIDAD Adaptabilidad 5
Capacidad para ser 3 12
instalado
Capacidad para ser 4
reemplazado
Realicen un análisis de los resultados y compárelos con los resultados generados a

través de una herramienta de software
69
Pruebas de calidad en Kiuwan
Se puede observar que tiene 23 vulnerabilidades muy altas, en cuanto a la cuestión del
control de flujo.
La parte más vulnerable del software es el código escrito en JavaScript.
70
En cuanto a los módulos, la mayoría no son seguros, se deben implementar medidas de

seguridad.
Basados en los resultados de la tabla anterior podemos concluir que el software es

funcional, pero no tan seguro como se creía que fuese, aunque el software cumple con los
requisitos previamente estipulados en la etapa de planeación, se debe mejorar la
seguridad para brindar la garantía del intercambio de datos entre el cliente y el servidor.
71
CONCLUSION
Gracias a las métricas de calidad de software podemos ver la calidad de nuestro producto,
en este caso una aplicación web, además saber la conformidad del cliente e identificar el
grado en el que se encuentra el producto.
La obtención de un software con calidad implica la utilización de metodologías o

procedimientos estándares para el análisis, diseño, programación y pruebas del software
que permitan uniformar la filosofía de trabajo, para lograr una mayor confiabilidad,
mantenibilidad y facilidad de prueba, que eleven a la vez la productividad, tanto para la
labor de desarrollo como para el control de la calidad del software.
72

Sergio Andrés Díaz Hernandez

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Sergio Andrés Díaz Hernandez

Загружено:

Авторское право:

Доступные форматы

UNIVERSIDAD POPULAR DEL CESAR

Aplicación web para la gestión académica de la Institución

APLICACIÓN WEB PARA LA GESTIÓN ACADEMICA DE LA INSTITUCION EDUCATIVA

SERGIO ANDRÉS DÍAZ HERNÁNDEZ

JURGEN HASSLER CORDOBA DE LA CRUZ

FACULTAD DE INGENIERIA Y TECNOLOGIAS

UNIVERSIDAD POPULAR DEL CESAR

2.4. Técnicas y tipos de pruebas

3.1. Pruebas unitarias

3.1.1. Pruebas de caga negra

3.1.1.1. Especificación de particiones de equivalencias

3.1.1.2. Diseño de casos de pruebas

3.1.1.3. Casos de prueba de valores limites

3.1.2. Pruebas de caja blanca

3.1.2.1. Complejidad ciclomatica de McCabe

3.1.2.2. Diseños de casos de prueba

3.2. Pruebas de integración

3.2.1. Técnicas de pruebas incrementales

3.2.1.1. Prueba incremental ascendente

3.2.1.2. Prueba incremental descendente

3.2.1.3. Pruebas de integración basada en hilos

3.2.1.4. Uso de la herramienta Katalon

4. Métricas del software

4.1.3. Tipos y herramientas de métricas

4.2. Formulación y recolección de datos

4.2.1. Medidas del tamaño del producto

4.2.2. Métricas CK Chindambe, Kemerer y Lorenz y Kidd

4.2.3. Métricas de funcionalidad

4.2.4. Herramienta utilizada para el análisis de software

4.2.5. Métricas utilizando el método GQM

5. Estimación del software

5.1. Estimación del tamaño usando el método PROBE

5.2. Estimación del tamaño usando puntos de casos de uso

5.3. Estimación de costo aplicando método COCOMO II

5.4. Utilice una herramienta para obtener resultados de COCOMO II

PRUEBAS DEL SOFTWARE

La prueba de software es un elemento crítico para la garantía del correcto

Encontrar el mayor número de fallos en el producto software en la menor cantidad

• Comprobar si el producto software hace lo que debe hacer, es decir, si los

• Detectar defectos en el software.

• Identificar y asegurar que los defectos encontrados se han corregido antes

 Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes

El propósito del plan de pruebas es proveer la información necesaria para planear y

1.4 Estrategias de pruebas

1.4.1 Pruebas Unitarias

Objetivo de la prueba: Comprobar que cada uno de los

Responsables Jurgen Hassler Córdoba

Criterios de evaluación: Cada uno de los módulos a probar deben

1.4.2 Pruebas de Integración

Objetivo de la prueba: Comprobar si un módulo puede tener

Responsables Sergio Andrés Díaz Hernández

Criterios de evaluación: Exitosa

1.4.3 Pruebas de aceptación

Objetivo de la prueba: Validar conjuntamente con el cliente,

Responsables Sergio Andrés Díaz Hernández

Criterios de evaluación: Mostrar personalmente el funcionamiento

Las pruebas unitarias tienen como objetivo verificar la funcionalidad y

Pruebas de Caja Negra

Estas pruebas se basan en la especificación del programa o componente a

2.2 PRUEBAS UNITARIAS

2.2.1 Especificación de particiones de equivalencia

Condición de Entrada Clases Validas Clases Invalidas

Código estudiante. 1)codigo≤9999999999 3)código >9999999999