Modelo para evaluar un RED

Después de realizar un análisis de los diferentes modelos de evaluación de la calidad de Software, como grupo hemos determinado que existen dos modelos con los que podemos trabajar la evaluación de un RED y a continuación explicamos las razones por las cuales consideramos son los más indicados para dicha labor, sin desconocer la importancia de los demás modelos.

ISO 9621:  Por ser uno de los estándares más conocidos y con mayor reputación. El Software analizado bajo este modelo permite el análisis en cada una de sus versiones y evoluciones, viendo cómo actúa en cada fase del desarrollo de software para garantizar un producto final de la más alta calidad. También es de entender que existen modelos que se aplican no solo a la complejidad del software sino a la capacidad empresarial para asumir el reto de ofrecer al usuario un producto de calidad, es ahí donde se encuentra igualmente la importancia del estándar ISO 9621 que puede aplicarse no solo a software a medida sino a pequeñas empresas desarrolladoras de aplicaciones.

Modelo McCall:  Es casi el padre de los modelos de evaluación y al igual que ISO 9621, no solo es para las grandes empresas y es versátil en la evaluación de cualquier proyecto de software.  De los aspectos más importantes cabe resaltar que existe una infinidad de información y ejemplos de implementación con los cuales podemos guiarnos para poner a prueba el modelo. 

 

Debemos tener en cuenta que hoy en día el desarrollo de software depende del procedimiento que el desarrollador defina para la creación de aplicaciones y con el auge de las nuevas tecnologías informáticas y de lenguajes de programación, casi cualquier persona puede asumir el reto de realizar su propio proyecto de software como es el caso de JAVA, Kotlin, IOS, PYTHON, lenguajes de programación al alcance de todos y en los cuales se pueden desarrollar pequeñas aplicaciones a las cuales también se aplican modelos de evaluación de calidad como ISO 25000

En fin concluimos que dependiendo igualmente del grado de desarrollo y complejidad del software se debe escoger el modelo de evaluación de calidad.

MODELO BOEHM

Barry Boehm

BOEHM

Este modelo fue propuesto por Barry Boehm en el año de 1978. Este se basa en que el software debe hacer lo que el usuario quiere que haga, por lo tanto, se espera que el software:

• Utilice los recursos del computador correcta y eficientemente
• Sea fácil de usar y de aprender para los usuarios
• Estar bien diseñado, codificado y ser probado y mantenido fácilmente.

Es el segundo modelo de calidad más conocido, este modelo introduce características de alto nivel, características de nivel intermedio y características primitivas, cada una de las cuales contribuye al nivel general de calidad.

La estructura presenta 3 niveles para las características: de alto nivel, de nivel intermedio y características primitivas. Cada una de estas características contribuye al nivel general de calidad.

 

CARACTERÍSTICAS

Fuertes Castro, V.M., resume las explicaciones dadas por Bohem la calidad de este modelo que debe verificar el código de la siguiente manera:

• Accesibilidad: facilidad en el uso selectivo de sus partes.
• Aumentabilidad: el código puede acoger fácilmente una ampliación de los requisitos de funcionalidad o de almacenamiento de datos.
• Auto-contenido: efectúa todas sus funciones implícitas y explícitas sin requerir nada del exterior.
• Auto-descriptivo: contiene suficiente información para que un lector determine o verifique sus objetivos, suposiciones, restricciones, entradas, salidas, componentes y estado.
• Completitud: se encuentran presentes todas sus partes y cada una está desarrollada totalmente. · Comprensibilidad: su propósito resulta claro para quien lo inspeccione.
• Comunicatividad: facilita la especificación de las entradas y proporciona salidas cuya forma y contenidos son útiles y fáciles de asimilar.
• Concisión: no hay un exceso de información.
• Consistencia: el código presenta consistencia interna si contiene una notación, terminología y simbología uniforme, y presenta consistencia externa si su contenido concuerda con los requerimientos.
• Eficiencia de dispositivos: los dispositivos se utilizan eficientemente.
• Eficiencia: cumple todos sus objetivos sin desperdicio de recursos.
• Estructuración: posee un patrón definitivo de la organización de sus partes interrelacionadas.
• Fácil de probar: facilita el establecimiento de criterios de verificación y favorece la evaluación de su rendimiento.
• Fiabilidad: capacidad de desarrollar todas sus funciones satisfactoriamente.
• Independencia del dispositivo: puede ejecutarse en ordenadores de la misma arquitectura con diferentes configuraciones hardware a la usada en el desarrollo.
• Ingeniería humana: cumple todos sus objetivos sin desperdiciar el tiempo ni la energía de los usuarios y sin degradar su moral.
• Legibilidad: puede distinguirse fácilmente su función mediante una lectura del código.
• Mantenibilidad: facilidad de actualización para satisfacer nuevos requerimientos o corregir deficiencias.
• Modificabilidad: facilidad para incorporar cambios una vez que se ha determinado la naturaleza de los cambios deseados.
• Precisión: las salidas tienen la exactitud suficiente.
• Robustez/integridad: capacidad para seguir funcionando aunque se produzcan algunas violaciones de los supuestos asumidos en la especificación.
• Seguimiento: favorece las mediciones sobre el uso del código.
• Transportabilidad: capacidad del sistema para ser manejado bien y sin dificultad en configuraciones y arquitecturas distintas a la del desarrollo.
• Utilidad general: la utilizabilidad, mantenibilidad y transportabilidad son condiciones necesarias para alcanzar la utilidad general.
• Utilizabilidad (utilidad tal cual): es fiable, eficiente y adaptado al usuario humano.

Fuente: Fuertes Castro, J.L.(2002)

 

METRICAS

 

Fuente: Rojas Esquivel, M.A. (2018)

VENTAJAS Y DESVENTAJAS

 

Ventajas 

• Une los mejores elementos de otros modelos.
• Integra el desarrollo del software con el mantenimiento.
• Sus características primitivas son varias y orientadas a diferentes niveles.

 

Desventajas 

• Genera mucho tiempo el análisis.
• Es un modelo costoso.
• Funciona mejor en grandes proyectos.
• Se trabaja siguiendo un protocolo y debe ser seguido estrictamente para un buen funcionamiento.

 

Para mayor información

http://oa.upm.es/34988/1/TD_Fuertes_JOSE_LUIS.pdf

MODELO FURPS

MODELO FURPS

Modelo desarrollado por Hewlett-Packard, cuyo nombre proviene de los criterios que evalúa: Funcionalidad, usabilidad, confiabilidad (reliability), desempeño (performance) y soportabilidad.

 

CARACTERÍSTICAS

Este modelo se reconoce como un modelo de calidad fijo el cual es usado para realizar la evaluación de la calidad de un producto.

La dinámica de evaluación contempla dos requerimientos, el primero en el que se asignan prioridades y el segundo donde de definen los atributos de calidad que pueden ser medidos. (Chinchilla, 2016), por lo tanto:

Los requerimientos funcionales (F): Especifican funciones que el sistema debe ser capaz de realizar, sin tomar restricciones físicas a consideración, y se definen a través de las entradas y salidas esperadas.

Los requerimientos no funcionales (URPS): Usability (Facilidad de uso), Reliability (Confiabilidad), Performance y Supportability (Facilidad de soporte). describen atributos del sistema o atributos del ambiente del sistema.

El modelo FURPS+ incluye, además de los factores de calidad y los atributos, restricciones de diseño y requerimientos de implementación, físicos y de interfaz. El "+" en FURPS + indica auxiliares y subfactores, como:

Restricciones de diseño:  una restricción de diseño, como su nombre lo indica, limita el diseño; por ejemplo, requerir una base de datos relacional estipula el enfoque que adoptamos para desarrollar el sistema.

Restricciones de implementación:  una restricción de implementación pone límites a la codificación o la construcción: estándares, plataforma o lenguaje de implementación.

Restricciones de interfaz:  una restricción de interfaz es un requisito para interactuar con un elemento externo. Cuando se desarrolla dentro de una empresa, a menudo tiene que interactuar con sistemas externos.

Restricciones físicas: las restricciones físicas afectan el hardware utilizado para albergar el sistema, por ejemplo, la forma, el tamaño y el peso.

 

MÉTRICAS

Las características y subcaracterísticas, pueden ser utilizadas para generar métricas de calidad para todas las actividades del proceso del desarrollo del software.

VENTAJAS Y DESVENTAJAS

 

VENTAJAS

• Permite reducir los riesgos de no considerar alguna de las facetas del desarrollo de un sistema.
• Permite estandarizar algunos criterios para poder obtener los requerimientos
• Los criterios son claramente entendibles, esto implica su fácil utilización.
• Tiene en cuenta las fallas en el producto y en el proceso esto permite una mayor corrección. Se podría utilizar no para una sino para varios proyectos.
• En cierta forma su división en factores funcionales y no funcionales son convenientes para determinar la calidad aún así hay restricciones básicas

 

 

DESVENTAJAS

• Al igual que el modelo MCCall, se necesita de muestras métricas lo que implica un mayor esfuerzo de tiempo y costo.
• Una limitación de este modelo de calidad es que no tiene en cuenta la portabilidad de los productos software que se estén considerando, factor digno de consideración en función de las exigencias actuales que recaen sobre el proceso de desarrollo del software.

 

Para mayor profundidad

MODELO GQM

Según  (Universidad Pedagógica y Tecnológica de Colombia, Tunja - Colombia et al., 2017) el modelo de calidad GQM o Goal Question Metric:  “ Se enfoca a proporcionar una forma que permita definir métricas para medir el avance como los resultados de algún proyecto, a partir de la aplicación de unas preguntas relacionadas con el proyecto, que permitan alcanzar unas metas previamente planteadas, el modelo trabaja sobre metas, preguntas y métricas”.

  

CARACTERÍSTICAS

El modelo GQM se puede aplicar a todo el ciclo de vida del producto, procesos, y   recursos y se pude alinear fácilmente con el ambiente organizacional.

·   Puede ser utilizado por los miembros individuales de un equipo de proyecto para: Enfocar su trabajo y determinar su progreso hacia la realización de sus   metas específicas.

  Los objetivos de la organización se definen primero como: mejorar calidad, confiabilidad, reducir costos, disminuir riesgos, mejorar tiempos entre otros.

Basili describió el proceso de GQM en seis pasos:

 

1. Establecer las Metas: Desarrollar un conjunto de metas corporativas, de la división y del proyecto de negocio  que estén asociados a  un conjunto de medidas de productividad y calidad.

Fuente: Estrada F. y Maya E., 2016

2. Generación de Preguntas: Generar las preguntas (basadas en modelos) que definen objetivos de la manera más completa y cuantificable posible.
3. Especificación de Medidas: Especificar las medidas necesarias a ser recolectadas para contestar las preguntas y seguir la evolución del proceso y  producto con respecto a las metas.
4. Preparar Recolección de datos: Desarrollar mecanismos para la recolección de datos.
5. Recolectar, Validar y Analizar los datos para la toma de decisiones: Recoger, validar y analizar los datos en tiempo real, para proporcionar la realimentación  de proyectos  en una acción correctiva.
6. Analizar los datos para el logro de los objetivos y el aprendizaje: Analizar los datos una vez alcanzado una meta para determinar el grado de conformidad y hacer las recomendaciones para mejoras futuras.

 

 MÉTRICAS

El modelo GQM proporciona una manera útil para definir mediciones tanto del proceso como de los resultados de un proyecto. Considera que un programa de medición puede ser más satisfactorio si es diseñado teniendo en mente las metas u objetivos perseguidos. Este paradigma provee un enfoque que permite establecer un sistema de medición por objetivos para el desarrollo de software, en el cual, el equipo empieza con las metas organizacionales, define los objetivos de medición, plantea preguntas para hacer frente a las metas, e identifica métricas que dan respuestas a las preguntas (OMG, 2012).

Fundamento Jerárquico de GQM, (Basili et al 1994)

 

 VENTAJAS Y DESVENTAJAS

 

Ventajas:

• Se puede aplicar a todo el ciclo de vida del producto, procesos, y recursos y se puede alinear fácilmente con el ambiente organizacional.
• Evitar decrecimiento en ventas debido a la mejora calidad
• Ahorro de tiempo y esfuerzo en el desarrollo de software debido a un mejor entendimiento de los procesos de desarrollo.

 

Desventajas

• Es efectivo cuando es implementado como parte de una iniciativa de mejora de la calidad más amplia, ya que uno de los principales propósitos de las mediciones es la mejora. El equipo de GQM necesitará coordinar estas tareas para todos los proyectos de forma tal de asegurar consistencia de las métricas entre proyectos.
• Compra de hardware y software adicional para dar soporte al programa de medición
• Tiempo empleado por el equipo GQM para procesar los datos de la medición y preparar las sesiones de realimentación
• El proceso de interpretación de las medidas de las métricas no está bien definido y cuando interviene muchas métricas puede ser difícil de análisis, implementación y recomendación.

 

Para mayor profundización:

MODELO MCCALL

 

CARACTERÍSTICAS

Este modelo busca reducir la brecha entre usuarios y desarrolladores enfocándose en un número de factores de calidad que reflejen las prioridades de ambos. El modelo de McCall organiza los factores en tres ejes o puntos de vista desde los cuales el usuario puede contemplar la calidad de un producto, basándose en once factores de calidad organizados en torno a los tres ejes y a su vez cada factor se desglosa en criterios de calidad.

CAPACIDADES Y FACTORES PROPUESTOS POR McCall

CAPACIDAD	FACTOR	MÉTRICA
Operación	Corrección: Grado de cumplimiento de las especificaciones y objetivos del usuario	Compleción
		Consistencia
		Trazabilidad
	Confiabilidad: Grado en el sistema está disponible para usarse.	Complejidad
		Consistencia
		Exactitud
		Modularidad
		Simplicidad
		Tolerancia a errores
	Usabilidad: Grado de esfuerzo necesario que se requiere para aprender a utilizarlo.	Facilidad de formación
		Operatividad
	Integridad o Seguridad: Grado en el que se controla el acceso al programa o los datos por usuarios no autorizados.	Facilidad de auditoria
		Instrumentación
		Seguridad
	Eficiencia o Performance: Cantidad de recursos y código requeridos por un programa para realizar una función.	Concisión
		Eficiencia de ejecución.
		Operatividad
Transición	Portabilidad: Grado que mide el esfuerzo para migrar un programa de un entorno de operación a otro.	Auto documentación
		Generalidad
		Modularidad
	Reusabilidad: Grado de esfuerzo requerido para que el programa o una de sus partes pueda ser utilizado en otro proyecto.	Auto documentación
		Generalidad
		Independencia hardware
		Independencia del sistema
		Modularidad
	Interoperabilidad: Grado de esfuerzo dedicado para que un sistema o programa pueda operar conjuntamente con otro.	Estd. Comunicaciones
		Estandarización de datos
Revisión	Facilidad Mantenimiento: Esfuerzo requerido para localizar y corregir un error en un programa en funcionamiento.	Auto documentación
		Concisión
		Consistencia
		Instrumentación
		Modularidad
		Simplicidad
	Flexibilidad: Esfuerzo requerido para modificar un software en funcionamiento.	Auto documentación
		Capacidad de expansión
		Complejidad
		Concisión
		Consistencia
		Generalidad
		Modularidad
		Simplicidad
	Facilidad de Prueba: Grado de esfuerzo requerido para probar un programa verificando que realice adecuadamente sus funciones.	Auto documentación
		Complejidad
		Facilidad de auditoria
		Instrumentación
		Modularidad
		Simplicidad

MÉTRICAS DE CALIDAD

La medición de cualquiera de estos factores está definida en este modelo en base a 41 métricas.  Para cada criterio existe una lista de condiciones que se deben cumplir en distintas etapas: Requerimientos (R), Diseño(D), Implementación (I).  Se cuentan las condiciones que se satisfacen en cada una de las etapas, sobre el total posible.        

Eso da una medida del criterio, que se pondera en partes para medir el factor con los otros criterios asociados al factor.

En la Tabla  se presentan detalladamente las capacidades y factores propuestos por McCall.

MÉTRICA	SIGNIFICADO
Auto documentación	Grado en que el código fuente brinda información de documentación importante.
Capacidad de expansión	Grado permitido de ampliación del diseño de la arquitectura de datos o procedural.
Compleción de las funciones	Grado en que se pudieron implementar las funciones requeridas.
Complejidad	Complejidad del sistema
Concisión	Densidad del programa en relación a las líneas de código.
Consistencia	Diseño uniforme del programa empleando técnicas de documentación.
Eficiencia de ejecución	Rendimiento en tiempo de ejecución
Estandarización de comunicaciones	Grado de uso de estándares y protocolos.
Estandarización de datos y estructuras	Manejo de tipos de datos y estructuras uniformes a lo largo del programa.
Exactitud de cálculo y de control	Precisión obtenida en los cálculos
Facilidad de auditoría	Facilidad de comprobación
Independencia del hardware	Grado de desacople del software en relación al Hardware donde opera.
Independencia del software	Grado de independencia del software en relación al sistema operativo, y otras limitaciones del entorno.
Instrumentación	Grado de auto-vigilancia en el funcionamiento e identificaciones de errores.
Modularidad	Independencia funcional de los componentes.
Operatividad	Facilidad de operación
Seguridad	Disponibilidad de elementos de protección del programa y la información.
Simplicidad	Grado de la dificultad para entender el Software
Tolerancia a errores	Grado de afectación causado por un error.
Trazabilidad	Capacidad de seguimiento y asociación de los requisitos con los elementos de diseño.

VENTAJAS 

• Existe una relación entre los desarrolladores y el usuario.
• Evalúa el producto a nivel alto.
• Utiliza niveles jerárquicos.
• Es práctico y fácil de entender y de esta forma fácil de aplicar, esto debido a su estructura jerárquica.
• Identifica atributos claves desde el punto de vista del usuario.
• Se focaliza en el producto final y en medidas precisas de alto nivel orientado al producto final, pero, se puede aplicar al proceso.
• Se puede utilizar no para varios proyectos al mismo tiempo.
• En costos resulta viable es de gran ayuda para cualquier organización
• Identifica una serie de criterios, tales como rastreabilidad, simplicidad, capacidad de expansión, etc.

  

DESVENTAJAS

• Es difícil que las características y sub-características sean siempre perfectamente independientes.
• Falta una asociación explicita entre el modelo y el proceso.
• No siempre existe una relación perfectamente lineal entre los valores las métricas y las características que deben estimar.
• Las características son en general propiedades abstractas medibles mediante métricas, lo cual implica un trabajo tedioso por la cantidad de métricas que se utilizarían.
• Implica un trabajo adicional al proceso, debido a que se evalúan muchos factores.
• No siempre existe una relación perfectamente lineal entre los valores métricos y las características que se deben estimar.
• La idea del modelo es la descomposición del concepto genérico de calidad en tres capacidades importantes para un producto software y a su vez cada capacidad se descompone en un conjunto de factores y finalmente se definen criterios para evaluar el factor a través de métricas que indican en qué medida el sistema posee una característica dada.

Para más información sobre el modelo Mccall podemos visitar los siguientes sitios.

 

Modelo de calidad de McCall

https://modelos-de-evaluacion-de-rd.fandom.com/es/wiki/Modelo_de_calidad_de_McCall