MODULO EVALUACION DE CALIDAD

DE LA TECNOLOGIA EDUCATIVA

POR:

SIGILFREDO ZABALA

TUTOR:

JORGE LUIS ESCOBAR REYNEL

UNIVERSIDAD DE SANTANDER UDES

MAESTRÍA EN GESTIÓN DE LA TECNOLOGÍA EDUCATIVA

MONTERÍA – CÓRDOBA

AÑO 2019
 INTRODUCCIÓN

La Industria del software desde su surgimiento ha influido notablemente en el

desarrollo de las empresas, Sin embargo los propósitos de la mayoría de software no

cumplen con el cronograma, el cálculo o las funciones requeridas. Por lo tanto, existen

modelos y estándares de calidad que ayudan a las organizaciones a estructurar de manera

coherente sus procesos y productos, esas organizaciones son las siguientes: el Modelo de

McCall, el Modelo de Boehm, el Modelo de Furps, el Modelo CMM, el Modelo GILB, la

norma ISO/IEC 9126 y la ISO/IEC 25010,

MODELOS CARACTERÍSTICAS VENTAJAS DESVENTAJAS
Este modelo busca reducir la brecha entre usuarios y  Existe una relación  Se evalúan muchos
desarrolladores enfocándose en un número de directa entre los factores lo que implicaría
factores de calidad que reflejan las prioridades de desarrolladores y el un trabajo adicional al
ambos. Los factores se centran en tres aspectos usuario proceso.
importantes de un producto de software.  Evalúa el producto a  Implicaría un trabajo
1. Operación del producto: sus características nivel bajo. tedioso por la cantidad de
MODELO
MCCALL operativas.  Utiliza niveles métricas que se utilizarían
2. Revisión del producto: su capacidad para jerárquicos
soportar los cambios.
3. Transición del producto: su adaptabilidad a
nuevos entornos.
Este define la calidad de software en términos de  Su fundamentó en el  Genera mucho tiempo en
atributos cualitativos y los mide usando métricas. modelo McCall, sus el desarrollo del sistema.
La estructura jerárquica del modelo métricas apuntan a la  La implementación del
se presenta en niveles calidad del software. modelo es costoso se
1. Características: Alto nivel, intermedio y  Involucra menos factores requiere experiencia para
primitivas que permiten un menor identificar los riesgos.
MODELO 2. Factores de calidad: Utilidad, tiempo en el momento  No especifica muchos
BOEHM Mantenimiento de portabilidad, de evaluar. aspectos relacionados con
confiabilidad, eficiencia, usabilidad,  Se podría utilizar no para el usuario
 habilidad, comprensibilidad, uno sino para varios
modificabilidad. proyectos.
3. Criterios: independencia, completitud,
exactitud, consistencia, eficiencia,
accesibilidad, comunicatividad,
estructuración, auto descriptividad,
concisión, legibilidad, expansividad
Se basan en la funcionalidad, facilidad de uso,  Los criterios son  Se necesitan de muchas
confiabilidad, performance y facilidad de soporte), y claramente, entendibles, métricas lo que implica un
por otro que los requisitos se clasifiquen en dos lo que implica su fácil mayor esfuerzo de tiempo
categorías: requisitos funcionales, que son los que utilización. y costo
especifican funciones que el sistema debe ser capaz  En cierta forma su  Se establecen restricciones
de realizar sin tener en cuenta las restricciones división en factores en el diseño y los
MODELO físicas y requerimientos no funcionales (URPS), que funcionales y no requerimientos de
FURPS puntualizan atributos del sistema o del medio funcionales es implementación físicos y
ambiente del sistema. convenientes para de interfaz
1. Requisitos Funcionales: Funcionalidad determinar la calidad,
2. Requisitos no Funcionales: Usabilidad, aun así, hayan
Confiabilidad, desempeño, capacidad de restricciones físicas.
soporte.  Tiene en cuenta las fallas
en el producto y en el
 proceso, esto permite
una mayor corrección.
 Se podría utilizar no para
uno sino para varios
proyectos
Estudia los procesos de desarrollo de software de  Practico de implementar  Falta mejorar el enfoque a
una organización y produce una evaluación de la mejorando la fiabilidad, la implementación de las
MODELO madurez de la organización según una escala de 5 mejorando así la calidad TIC
CMM niveles. La madurez de un proceso es un indicador del producto, y
de la capacidad para construir un software de reduciendo el número de
calidad. defectos