domingo, 6 de diciembre de 2020

GENERALIDADES DE NORMAS ISO 25000

Descripción 
El objetivo general de la creación del estándar ISO 25000 SQuaRE (Software Product Quality Requeriments and Evaluation) es organizar, enriquecer y unificar las series que cubren dos procesos principales: especificación de requerimientos de calidad del software y evaluación de la calidad del software, soportada por el proceso de medición de calidad del software. 

La ISO 25000, proporciona una guía para el uso de las series de estándares internacionales llamados requisitos y Evaluación de Calidad de Productos Software (SQuaRE). La norma establece criterios para la especificación de requisitos de calidad de productos software, sus métricas y su evaluación, e incluye un modelo de calidad para unificar las definiciones de calidad de los clientes con los atributos en el proceso de desarrollo.

Estándares y modelos de calidad de software 

Los modelos que se presentaran son:

*Modelo Boehm

*Modelo ISO9126

*Modelo GQM

*Modelo FURPS

*Modelo McCall

*Modelo GILB

 


MODELOS DE CALIDAD DEL SOFTWARE

 Contextualización de calidad de software

Es importante conocer los conceptos y características acerca de lo que es la calidad de software, y en cuanto a los modelos de calidad de software, su estructura y enfoque.

Calidad de software

El término calidad de software se refiere al grado de desempeño de las principales características con las que debe cumplir un sistema computacional durante su ciclo de vida, dichas características de cierta manera garantizan que el cliente cuente con un sistema confiable, lo cual aumenta su satisfacción frente a la funcionalidad y eficiencia del sistema construido.

El concepto de calidad de software, según Pressman (2010) se asocia a la “concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo plenamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente”, con base en los requisitos funcionales y no funcionales identificados en la etapa de análisis del sistema, insumo principal para implementar dichos requisitos con los atributos mínimos de calidad, fomentando la aplicación de procesos estandarizados y criterios necesarios en cada una de sus etapas, así se fomenta que el avance en el ciclo de vida del software minimice el riesgo de fracaso del proyecto. Por su parte, el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE, 1990) define calidad de software como “el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”, denotando que el énfasis radica en los requisitos específicos del sistema y en la búsqueda de la satisfacción del cliente.

Para garantizar la calidad de software es importante implementar algún modelo o estándar de calidad que permita la gestión de atributos en el proceso de construcción de software, teniendo en cuenta que la concordancia de los requisitos y su construcción son la base de las medidas de calidad establecidas.

Modelos de calidad de software

Aunque modelo y metodología distan en su definición, se rescata la cita dada por Moszkowitz (2010) en la que presenta una metodología que permite a cualquier organización realizar una autoevaluación o autodiagnóstico, por medio de una revisión sistemática de sus estrategias y prácticas de gestión. En el caso de la calidad de software el modelo debe ir enfocado a hacer seguimiento y evaluación a cada etapa de construcción del producto software. Por otro lado se menciona (Scalone, 2006) que “los modelos de calidad son aquellos documentos que integran la mayor parte de las mejores prácticas, proponen temas de administración en los que cada organización debe hacer énfasis, integran diferentes prácticas dirigidas a los procesos clave y permiten medir los avances en calidad”.

Esta definición, enfocada a la calidad del software, identifica que la organización debe contar con un proceso que como soporte al mismo lleve una documentación, y se valga de distintas prácticas definidas en el modelo, dando apoyo a la organización para tener una mejora continua y ser más competentes, para así poder medir la calidad y brindar productor o servicios de alto nivel.

En el ámbito de la construcción de software, el modelo de calidad debe permitir evaluar el sistema, bien sea cualitativa o cuantitativamente, y de acuerdo con esta evaluación la organización podrá proponer e implementar estrategias que permitan la mejora del proceso dentro de las etapas de análisis, diseño, desarrollo y pruebas del software.




MODELO DE CALIDAD GILB

El modelo de Gilb aparece alrededor de los años 1986 - 1988. Este modelo busca medir la capacidad del sistema para ejecutar tareas. Tiene como sub-atributos la capacidad de almacenamiento, capacidad de proceso y capacidad de respuesta.

Disponibilidad: Este atributo mide la capacidad del sistema para realizar un trabajo de forma útil.

Adaptabilidad: Hace referencia a la medida de la capacidad que tiene el sistema para sufrir modificaciones.

Utilizabilidad: Mide la facilidad con la cual las personas serán capaces y estarán motivadas para hacer uso del sistema.

El modelo proporciona ciertas características que proveen indicadores útiles para describir la calidad de la aplicación del sistema y usa métricas detalladas para dicho fin.   
























VENTAJAS

. Este modelo evalúa el producto de manera independiente.
. Al igual que otros procesos utiliza niveles de jerarquías para delegar trabajos.

DESVENTAJAS

. Se evalúan muchos factores que provocan un mayor trabajo en tiempo y costo.






MODELO GQM

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 DEL GQM

·     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:
·      Mejorar calidad
·      Confiabilidad, etc
·       Reduciendo costos, riesgos, mejorando tiempos, etc.


Fundamentos de GQM

La literatura abierta describe GQM en términos de un proceso de seis pasos donde los tres primeros pasos se basan en usar las metas de negocio para conducir a la identificación de las verdaderas métricas y los últimos tres pasos se basan en recopilar los datos de las medidas y la fabricación del uso eficaz de las métricas para mejorar la toma de decisión. Basili describió el proceso de GQM en seis pasos GQM como sigue:

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.

Generación de Preguntas: Generar las preguntas (basadas en modelos) que definen objetivos de la manera más completa y cuantificable posible.

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.

Preparar Recolección de datos: Desarrollar mecanismos para la recolección de datos.

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.

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.Los primeros tres pasos del proceso de Basili son llamados a menudo como la la fase de definición de GQM provee la estructura de proceso para pasar al concepto de métricas significativas que, cuando se ponen en funcionamiento cuantifican los objetivos y proveen datos significativos para la toma de decisión. Las Metas identifican lo que queremos lograr; las preguntas, nos dicen si estamos satisfaciendo los objetivos o nos ayudan comprender cómo interpretarlos; y las métricas identifican las mediciones que son necesarias para responder a las preguntas y cuantificar el objetivo.

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.

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.


MODELO MCCALL

El modelo de evaluación de McCall fue uno de los primeros modelos en ser creados para dicho fin; éste nació en el año 1977. Este es un modelo que está considerado desde la percepción del usuario y propone una serie de factores los cuales son conocidos como factores de McCall. Este modelo busca realizar una descomposición del concepto genérico de calidad en 3 capacidades importantes las cuales son: Operación, Transición y Revisión. Cada una de estas capacidades tiene a su vez un conjunto de factores que finalmente definen ciertos criterios que permiten evaluar el producto por medio de métricas, que dan cuenta de la medida en la que el sistema evaluado posee cierta característica. Estas métricas cuentan con sus propios criterios o medidas que posibilitan la medición de la calidad. Lo anterior se da gracias a la relación existente entre los factores y las métricas de calidad pertenecientes a cada producto a evaluar.


En la imagen se puede evidenciar claramente cuáles son los criterios de calidad que el modelo de McCall posee con miras a realizar una medición menos complicada a través de métricas; ya que según Bahamon (2010) en su artículo Control de Calidad en el Software, los factores de calidad son difíciles de medir la mayoría de las veces, pero McCall con su modelo facilita un poco más la evaluación, permitiendo así validar la medida de calidad con que cuenta el producto (software) de manera menos compleja.

Este modelo de McCall al ser un modelo fijo provee un sistema de calidad de partida ya establecido a quien desee hacer uso del mismo. Al ser un modelo fijo ofrece ciertas ventajas y desventajas tales como:

VENTAJAS DEL MODELO

El factor de calidad es estándar (el mismo).

Se puede reutilizar para realizar la evaluación de otros productos.

DESVENTAJAS DEL MODELO

Al ser fijo da a entender que todos los criterios de evaluación serán idénticos y suficientes para evaluar todo tipo producto.

 

 

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 (Soto, 2015).

La Funcionalidad.

Define características y funciones del software, generalidad de las funciones y seguridad del sistema

La Usabilidad.

Se evalúa tomando en cuenta factores humanos (véase el capítulo 11), la estética general, la consistencia y la documentación.

La Confiabilidad.

Se evalúa con la medición de la frecuencia y gravedad de las fallas, la exactitud de los resultados que salen, el tiempo medio para que ocurra una falla (TMPF), la capacidad de recuperación ante ésta y lo predecible del programa.

El Rendimiento

Se mide con base en la velocidad de procesamiento, el tiempo de respuesta, el uso de recursos, el conjunto y la eficiencia.

La Mantenibilidad.

Combina la capacidad del programa para ser ampliable (extensibilidad), adaptable y servicial (estos tres atributos se denotan con un término más común: mantenibilidad), y además que pueda probarse, ser compatible y configurable (capacidad de organizar y controlar los elementos de la configuración del software, véase el capítulo 22) y que cuente con la facilidad para instalarse en el sistema y para que se

detecten los problemas. ===

 

No todo atributo de la calidad del software se pondera por igual al diseñarlo. Una aplicación tal vez se aboque a lo funcional con énfasis en la seguridad. Otra quizá busque rendimiento con la mira puesta en la velocidad de procesamiento. En una tercera se persigue la confiabilidad. Sin importar la ponderación, es importante observar que estos atributos de la calidad deben tomarse en cuenta cuando comienza el diseño, no cuando haya terminado éste y la construcción se encuentre en marcha.

Categorías de Requerimientos

  1. 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.
  2. 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.

Criterios de calidad y factores asociados

Funcionalidad - Los requisitos de funcionalidad deben incluir

  1. Conjunto de Características,
  1. Capacidades
  2. Seguridad

Facilidad de Uso - Deben incluir subcategorías tales como:

  1. Factores humanos.
  2. Estéticos.
  3. Consistencia en la Interfaz de Usuario.
  4. Ayuda en línea.
  5. Asistentes.
  6. Documentación del usuario.
  7. Material de capacitación.

Confiabilidad - Se considera requisitos de confiabilidad:

  1. Frecuencia y severidad de fallas.
  2. Recuperación a fallos.
  3. iempo entre fallos.

Performance (Rendimiento) - Un requisito de rendimiento impone condiciones a los requisitos funcionales. Por ejemplo a una acción dada , se pueden especificar los siguientes parámetros de rendimiento:

  1. Velocidad.
  2. Eficiencia.
  3. Disponibilidad.
  4. Tiempo de Respuesta.
  5. Tiempo de Recuperación.
  6. Utilización de Recursos.

Soporte - Los requisitos de soporte pueden incluir:

  1. Requisitos de instalación.
  2. Requisitos de Configuración.
  3. Requisitos de Adaptabilidad
  4. Requisitos de Compatibilidad.

 

 

MODELO BOEHM

Es un modelo de calidad fijo y fue propuesto por Barry W. Boehm en el año de 1978, y define la calidad del software en términos de atributos cualitativos y los mide usando métricas.

Este modelo contempla tres niveles jerárquicos: Las características de alto nivel, de nivel intermedio y las características primitivas todas contribuyen al nivel de calidad global.

Este modelo propone una jerarquía de niveles, en forma de un árbol con tres ramas principales, que permiten que el software sea de utilidad: Portabilidad, Facilidad de Uso y Facilidad de Mantenimiento. Se estructura en tres niveles: Aplicaciones primarias, Construcciones Intermedias (factores) y Construcciones Primitivas, y finalmente las Métricas que determinan los valores para los criterios (construcciones primitivas)

Criterios de calidad y factores asociados 

Los factores de calidad del modelo de Boehm se descomponen en criterios de evaluación que son llamados elementos primarios. A continuación de relacionan:




MODELO ISO 9126 y 25000

 Norma ISO/IEC 9126.-

ISO 9126-1 propone un modelo de calidad categorizando la calidad de los atributos software en seis características (funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad), las cuales son subdivididas en subcaracterísticas. Las subcaracterísticas pueden ser medidas con métricas internas o externas.

La calidad de uso es definida como “la capacidad del software que posibilita la obtención de objetivos específicos con efectividad, productividad, satisfacción y seguridad”.

La norma 9126-2 es un reporte técnico que contiene la terminología relacionada con las medidas de las métricas, el uso de las métricas en el proceso del ciclo de la vida y unos conjuntos básicos introductorios de métricas externas para cada característica y subcaracterística de calidad de software. Este informe proporciona al usuario una guía (o dirección) de métricas para la evaluación de planificación, selección de métricas, diseño de métricas, aplicación de métricas y interpretación de medidas de datos.
Es recomendable que las métricas internas tengan fuerte relación con las métricas externas para que puedan ser usadas para predecir los valores de las métricas externas.
La interpretación de las medidas se puede realizar de tres formas:
  • Ø Medida directa. Una medida directa es una medida de un atributo que no depende de las medidas de otros atributos.
  • Ø  Medida indirecta. Una medida indirecta es derivada de medidas de uno o más atributos.
  • Ø  Indicadores. Son aquellas medidas que pueden ser estimadas o predichas desde otras medidas.
  •  
  • Las métricas tienen unas propiedades deseables que se detallan a continuación:
  • Ø  Fiabilidad.
  • Ø  Indicabilidad.
  • Ø  Disponibilidad.
  • Ø  Corrección.
  • Ø  Imparcialidad.


El conjunto de métricas que contiene está organizadas por características y subcaracterísticas, donde cada métrica contiene:
  • Ø  Nombre.
  • Ø  Propósito.
  • Ø  Método de aplicación.
  • Ø  Medida, fórmula y cómputo de datos.
  • Ø  Interpretación del valor medido.
  • Ø  Tipo de escala.
  • Ø  Tipo de medida.
  • Ø  Fuente de medida.
  • Ø  Referencia a ISO/IEC 12207 SLCP.
  • Ø  Audiencia.


La norma 9126-3 proporciona métricas internas para medir los atributos de las características de calidad definidas en la norma 9126-1. Con las siguientes cualidades:
  • Ø  Se aplican a un producto de software no ejecutable.
  • Ø  Se aplican durante las etapas de desarrollo.
  • Ø  Permiten medir la calidad de los entregables intermedios.
  • Ø  Permiten predecir la calidad del producto final.
  • Ø  Permiten al usuario iniciar acciones correctivas temprano en el ciclo de desarrollo.


El conjunto de métricas están organizadas igualmente por características y subcaracterísticas, donde tiene los mismos campos que la norma ISO 9126-2. Por lo tanto existirá métricas de funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad. Las propiedades deseables son las siguientes: confiable, repetible, reproducible, disponible, indicable, correcta y con significado. Los pasos que se sugieren son los siguientes:
  • Ø  Identificación de los requisitos de calidad.
  • Ø  Especificación de la evaluación.
  • Ø  Diseño de la evaluación.
  • Ø  Ejecución de la evaluación.
  • Ø  Retroalimentación a la organización.



 3.       Norma ISO 25000.-
Recientemente ha aparecido una nueva versión de la norma 9126: la norma ISO/IEC 25000. Esta proporciona una guía para el uso de las nuevas series de estándares internacionales, llamados Requisitos y Evaluación de Calidad de Productos de Software (SQuaRE). Constituyen una serie de normas basadas en la ISO 9126 y en la ISO 14598.

software con la especificación y evaluación de requisitos de calidad. Establece criterios para la especificación de requisitos de calidad de productos de software, sus métricas y su evaluación. Incluye un modelo de calidad dividido en dos partes para unificar las definiciones de calidad de los clientes con los atributos en el proceso de desarrollo. SQuaRE está formada por las divisiones siguientes:

Ø  ISO/IEC 2500n. División de gestión de calidad. Los estándares que forman esta división definen todos los modelos comunes, términos y referencias a los que se alude en las demás divisiones de SQuaRE.
Ø  ISO/IEC 2501n. División del modelo de calidad. El estándar que conforma esta división presenta un modelo de calidad detallado, incluyendo características para la calidad interna, externa y en uso.
Ø  ISO/IEC 2502n. División de mediciones de calidad. Los estándares pertenecientes a esta división incluyen un modelo de referencia de calidad del producto de software, definiciones matemáticas de las métricas de calidad y una guía práctica para su aplicación. Presenta aplicaciones de métricas para la calidad de software interna, externa y en uso.
Ø  ISO/IEC 2503n. División de requisitos de calidad. Los estándares que forman parte de esta división ayudan a especificar los requisitos de calidad. Estos requisitos pueden ser usados en el proceso de especificación de requisitos de calidad para un producto de software que va a ser desarrollado ó como entrada para un proceso de evaluación. El proceso de definición de requisitos se guía por el establecido en la norma ISO/IEC 15288.
Ø  ISO/IEC 2504n. División de evaluación de la calidad. Estos estándares proporcionan requisitos, recomendaciones y guías para la evaluación de un producto de software, tanto si la llevan a cabo evaluadores, como clientes o desarrolladores.
Ø  ISO/IEC 25050–25099. Estándares de extensión SQuaRE. Incluyen requisitos para la calidad de productos de software “Off-The-Self” y para el formato común de la industria (CIF) para informes de usabilidad.
Ø  La norma ISO 25000 ha sido desarrollada por el subcomité SC 7 (Ingeniería de software y sistemas) del Comité Técnico Conjunto ISO/IEC JTC 1.

¿CON CUÁL MODELO SE IDENTIFICAN PARA EVALUAR UN RED Y POR QUÉ?

Consideramos que el modelo BOEHM, es uno de los modelos mas indicado para llevar a cabo la evaluación de un Recurso Educativo Digital ,teniendo en cuenta que es un modelo incremental, esta dividido en conjuntos de tareas, las cuales se ajustan a la cantidad de interacciones que el equipo defina y cada interacción se divide en cuatro sectores como son: planeación ,análisis de riesgo ,ingeniería y evaluación por lo tanto dentro de nuestro proceso de formación, encontramos factores esenciales que influyen de forma contundente, estos están totalmente ligados a la educación, por otro lado estos tienen unas directrices y unos lineamientos que contribuyen a la mejora de los estándares, es así que se plantea el concepto de modelo de calidad como eje central, dando la importancia que este elemento tiene en un proceso de evaluación de calidad. Se describen los diferentes tipos de modelos y las propiedades, para finalmente presentar algunos de los modelos de calidad más sobresalientes y poder entender a cabalidad estos y la importancia e influencia que estos tienen en la aplicación en los procesos enseñanza aprendizaje.



VIDEO EXPLICATIVO DEL BLOGGER




 

REFERENCIAS BIBLIOGRÁFICAS

 Aula Virtual Universidad de Cartagena (06 de diciembre de 2020). Estándares y modelos de calidad del software. Obtenido de https://aulavirtualunicartagena.co/publicaci/evaluacion/UNIDAD%203.pdf.

Callejas M, Alarcón A, Álvarez A.(18 de Septiembre de 2013). Modelos de calidad de software un estado de arte. Obtenido de http://www.scielo.org.co/pdf/entra/v13n1/1900-3803-entra-13-01-00236.pdf

Eras J.(2017). Conceptualización del Modelo Gilb. Obtenido de                                                                    http://www.scielo.org.co/pdf/entra/v13n1/1900-3803-entra-13-01-00236.pdf

Fandom (06 de diciembre de 2020). Modelo GQP. Obtenido de                                                        https://modelos-de-evaluacion-red-grupo9.fandom.com/wiki/MODELO_GQM

Fandom (06 de diciembre de 2020). Modelo McCall. Obtenido de                      https://www.youtube.com/watch?v=5qX4j6ox5ro&feature=youtu.be                                                       

Uñoja R. (14 de abril de 2012). Análisis comparativo de las normas de calidad para el desarrollo de software de maccall, iso/iec 9126 e iso 25000. Obtenido de                                                                             http://masteringenieriasoft.blogspot.com/2012/04/analisis-comparativo-de-las-normas-de.html


GENERALIDADES DE NORMAS ISO 25000

Descripción  El objetivo general de la creación del estándar ISO 25000 SQuaRE (Software Product Quality Requeriments and Evaluation) es orga...