Norma Ramal – Requisitos de la Calidad para Sistemas Informáticos y Productos de Software

En el taller del subcomité 7 efectuado el 9 de febrero se aprobó el proyecto de Norma Ramal – Requisitos de la Calidad para Sistemas Informáticos y Productos de Software. Dicho proyecto fue elaborado por el Centro Nacional de Calidad de Software (CALISOFT). El proyecto se le entregará al MINCOM con un aval elaborado por el SC7 sugiriendo su aprobación.

1

La Norma Ramal establece requisitos mínimos a cumplir por los software o sistemas que se desarrollen en Cuba en las características de adecuación funcional, seguridad, usabilidad,  eficacia de desempeño y fiabilidad.

ADECUACIÓN FUNCIONAL

Completitud funcional

  • Se debe garantizar que cada botón/vínculo de la aplicación haga una función.
  • Se debe garantizar que en el producto o sistema estén desarrolladas todas las funcionalidades.

Corrección funcional

  • Se debe garantizar que cada funcionalidad arroje resultados correctos.
  • Se debe garantizar con todas las combinaciones posibles, que cada campo esté validado correctamente.

Pertinencia funcional

  • Se debe garantizar que el usuario pueda completar una funcionalidad realizando el menor número de pasos posibles.

SEGURIDAD

Confidencialidad

  • Se deben proteger las conexiones autenticadas o que involucren funciones o información relevante.
  • Se debe proteger y preservar la información relevante.
  • No se deben mostrar mensajes con información que ayude a recopilar información sobre el producto o las configuraciones del servidor.
  • No se deben mostrar referencias hacia objetos internos de la aplicación.
  • Se debe controlar el receptor de escucha de las Bases de Datos.
  • No deben contener archivos innecesarios que sean creados como consecuencia de editar archivos de la aplicación, tras crear copias de seguridad, o al dejar en el árbol de directorio archivos antiguos o sin referencias.
  • Todos los elementos de la infraestructura deben ser revisados para asegurarse de que no contienen ninguna vulnerabilidad conocida, así como las herramientas administrativas usadas para el mantenimiento de los diferentes componentes.

Integridad

  • No se deben permitir ataques XSS.
  • No se deben permitir ataques CSRF.
  • No se deben permitir inyecciones de código.
  • No se debe permitir configuraciones que afecten (a corto o largo plazo) la integridad del sistema.

Autenticidad

  • Debe existir un mecanismo de autenticación personalizado para todos los usuarios del sistema, independientemente del rol que tengan.
  • No se deben utilizar cuentas suministradas por defecto.
  • No se debe permitir que se realicen ataques para recuperar cuentas de usuarios válidas (fuerza bruta).
  • No se debe permitir la creación de contraseñas débiles.
  • Debe ofrecer la posibilidad de que el usuario pueda cambiar su contraseña.
  • Debe controlarse el historial de las contraseñas con vistas a que el usuario no repita contraseñas utilizadas con anterioridad.
  • Se debe controlar el ciclo de vida de las contraseñas.
  • Se debe cerrar automáticamente la sesión de un usuario cuando ha estado inactivo durante un cierto lapso de tiempo.
  • Se debe destruir el ID de sesión luego de salir o cerrar el sistema.
  • No se deben exponer los identificadores de sesión, los mismos deben estar cifrados independientemente del tratamiento que se le dé al transporte de los datos.
  • No se debe tener accesibilidad o control por usuarios sin autorización a los ficheros o directorios que se encuentran fuera del directorio web raíz.
  • Un usuario estándar (no administrador) no debe tener acceso a modificar sus privilegios en la aplicación o los de otro usuario con su mismo rol.
  • Se debe actualizar inmediatamente la gestión que se realice sobre los usuarios (incluyendo roles y permisos).

Disponibilidad

  • No se debe permitir ataques de DoS.
  • No se debe presentar fallos de segmentación, o que se sobrescriban direcciones de memoria adyacentes. De igual manera validar el tamaño de entrada de los campos.

USABILIDAD

Operabilidad

  • Se debe distinguir de manera evidente en los formularios los campos “requeridos” y “opcionales”.
  • Se debe establecer el tamaño de las cajas de texto para introducir información en función del tamaño del dato que se va a escribir.
  • Se debe establecer en cada página o ventana puntos de salida (cancelar, cerrar) que permitan al usuario abandonar la tarea que se encuentra realizando.
  • Se debe brindar la posibilidad de volver a pasos anteriores para modificar los datos en un proceso que lo requiera.
  • Se debe mostrar un cambio visible cuando el cursor está apuntando a un elemento de acción, excluyendo los cambios de cursor.
  • Se debe utilizar tipos y tamaños de fuente legibles.
  • Se debe definir como máximo entre 80 y 100 caracteres para la longitud de línea de los bloques de texto.
  • Se debe dividir en párrafos de un máximo de entre 5 y 8 líneas de longitud los bloques de texto de gran tamaño.
  • Se deben resaltar los enlaces del menú cuando se seleccionan.
  • Se debe dejar espacio entre los elementos de acción (enlaces, botones).
  • Se debe posicionar el cursor en el primer campo donde se introduce dato.
  • Se debe proporcionar información y pedir confirmación cuando una acción tiene consecuencias.
  • Se debe proveer retroalimentación cuando una tarea ha sido completada exitosamente.
  • Se deben señalar los campos que contienen datos inválidos y ofrecer información que ilustre el error cometido.
  • No se debe presentar enlaces internos rotos o que no lleven a ninguna ventana.
  • No se debe presentar enlaces externos que no existan.
  • Se debe implementar validaciones antes de que el usuario envíe información.
  • Se debe detallar correctamente los gráficos y tablas utilizando sus atributos.
  • Se debe garantizar que los elementos que componen la interfaz estén en el idioma seleccionado.

Productos o sistemas para la Web:

  • Se debe mostrar accesos desde la página de inicio a las partes o secciones más importantes del sitio.
  • Se debe garantizar la compatibilidad con los navegadores: Mozilla Firefox, Google Chrome, Opera e Internet Explorer en los productos o sistemas diseñados para internet.
  • Se deben identificar los enlaces para que sean distinguibles sin necesidad de pasar el mouse por encima.
  • Se debe utilizar texto para los enlaces.
  • Se debe contar con un buscador que aparezca en una zona visible y en todas las páginas.
  • Se debe ubicar un acceso a la página de inicio en una zona visible, reconocible y en todas las páginas.
  • Se debe garantizar la visualización correcta de los contenidos multimedia.
  • Se debe utilizar de manera moderada las animaciones y efectos en movimiento constantes.
  • Se debe permitir la navegación en el sitio sin necesidad del desplazamiento horizontal.
  • Se debe cumplir con estándares de código HTML y CSS, definido por el W3C.
  • Se debe utilizar un tamaño de fuente igual o superior a los 14 px para los contenidos.
  • Se deben definir metadatos como: palabras claves, título de la publicación, autor y descripción.
  • Se debe informar al usuario de los programas de software adicionales requeridos.
  • Se debe permitir visualizar las páginas de impresión del contenido sin perder información.
  • Se debe informar en los mensajes de error cuáles son las acciones correctoras.
  • Se debe garantizar una interfaz adaptable a dispositivos móviles.
  • Se debe alinear el texto a la izquierda.

Para artefactos de tipo Sistema de Gestión:

  • Se debe permitir que el usuario sepa en qué parte de la estructura se encuentra.

Para artefactos de tipo Aplicaciones de Escritorio:

  • Se debe mostrar la opción de ayuda ligada a las funciones que se ofrecen, durante la interacción con la aplicación.

Cognoscibilidad

  • Se debe ofrecer una navegación sencilla para que los usuarios sin mucha experiencia puedan hacer uso del sistema.
  • Se debe emplear nombres estandarizados para las categorías de la navegación y las funcionalidades.
  • Se debe mantener constante la distribución y ubicación de los elementos estructurales que contienen las páginas o ventanas.
  • Se debe mantener la información organizada con categorías lógicas, fácilmente memorizables por el usuario.
  • Se debe mantener similitud entre tareas, diálogos y formularios.
  • Se debe utilizar aceleradores o accesos rápidos a operaciones frecuentes.
  • Se deben utilizar nombres para los botones de los formularios relacionados con la acción que realizan.
  • Se debe mostrar los mensajes de error en texto plano entendibles para los usuarios.
  • Se debe utilizar nombres en los enlaces iguales que los títulos de las páginas a las que dirigen.

Productos o sistemas para la Web:

  • Se debe usar una URL, entendible y fácil de recordar.
  • Se deben diferenciar de manera evidente los enlaces internos de los externos.

Reconocibilidad

  • Se debe emplear un lenguaje que sea similar al utilizado por el usuario final.
  • Se debe utilizar títulos que sean descriptivos y distintivos.
  • Se debe establecer quiénes son los responsables del sistema.
  • Se debe brindar información de contacto del equipo de soporte.
  • Se debe garantizar que los contenidos publicados se ajustan al perfil temático definido.

Productos o sistemas para la Web:

  • Se debe reflejar la identidad del producto, sistema, empresa.
  • Se debe comenzar cada pantalla con un título que describa su contenido.
  • Se debe utilizar íconos que identifiquen claramente lo que representan.
  • Se debe proporcionar información sobre los autores, referencias y fecha de publicación, de las publicaciones.

Protección ante errores de usuarios

  • Se debe mostrar indicaciones para completar los campos problemáticos en los formularios.
  • Se debe emplear opciones por defecto en los formularios, siempre que sea posible.
  • Se debe brindar la posibilidad de seleccionar la información de una lista en situaciones donde se pueden producir errores de escritura.
  • Se debe informar al usuario cuando se intenta salir o cerrar una ventana en la que hay trabajo sin guardar.

Estética de interfaz de usuario

  • Se debe diferenciar un ícono seleccionado de los no seleccionados.
  • Se debe utilizar íconos que sean conceptualmente distintos pero que mantengan la armonía entre ellos.
  • Se debe mantener una tipografía coherente en toda la aplicación.
  • Se debe establecer niveles de importancia de los contenidos.
  • Se deben utilizar los estilos tipográficos con moderación.
  • Se deben mostrar los elementos del diseño correctamente alineados y agrupados.
  • Se debe mostrar el menú en un lugar destacado.
  • Se debe centrar o justificar a la izquierda los títulos del menú.
  • Se debe mantener la consistencia entre las etiquetas de los campos.
  • Se debe garantizar que los elementos no textuales presenten buena resolución.
  • No deben existir errores ortográficos.

Productos o sistemas para la Web:

  • Se debe personalizar las páginas de error.
  • Se debe mostrar el logo de la organización en el mismo lugar en todas las páginas del sitio.
  • Se debe mostrar sin problemas la presentación y composición de las páginas en los navegadores Mozilla Firefox, Google Chrome, Opera, Internet Explorer.
  • Se debe mostrar sin problemas la presentación y composición de las páginas en las diferentes resoluciones de pantalla para las que fue concebido.

Para artefactos de tipo Aplicación de Escritorio:

  • Se debe contener un símbolo distinguible en la parte derecha de los elementos de los menús que llevan a abrir un submenú.
  • Se debe mantener el tamaño de las ventanas apropiado para los elementos que agrupa.
  • Se debe garantizar que no existan errores de redacción.

Accesibilidad

  • Se debe garantizar un correcto contraste de color entre el texto y el fondo.
  • Se debe disponer sin color la información que esté transmitida a través de colores.
  • Se debe proporcionar textos aclaratorios sobre imágenes de forma que puedan ser comprendidas por cualquier persona independientemente de la discapacidad poseída.
  • Se debe identificar el cambio de idioma en los textos.
  • Se deben proporcionar texto alternativo para elementos no textuales.
  • Se deben subtitular los elementos multimedia en los sistemas diseñados para la Web siempre que sea posible.

Productos o sistemas para la Web:

  • Se debe declarar el atributo lenguaje de las páginas para mejorar la pronunciación de los lectores de pantalla.

EFICIENCIA DE DESEMPEÑO

Rendimiento

  • Se deben atender las peticiones a la aplicación en un tiempo menor a los 5 segundos.
  • Se deben atender las peticiones a la BD en un tiempo inferior a los 3 segundos.

Utilización de los recursos

  • Se debe garantizar un consumo de CPU y RAM inferior al 80%.

Capacidad

  • Se debe asegurar que la cantidad mínima de usuarios conectados concurrentemente sea, en sistemas de alta concurrencia de 4000 usuarios, y en los de baja concurrencia de 500 usuarios.

FIABILIDAD

Madurez

  • Se deben mostrar personalizados los mensajes provenientes de las excepciones y/o errores que puedan ocurrir.
  • Se debe controlar la introducción de valores inválidos.
  • Se debe informar y actuar ante la caducidad de sesiones por inactividad o por cambio de permiso.

Tolerancia ante fallos

  • Se deben contener los errores producidos en las bases de datos.
  • Se debe proteger la información del sistema ante la pérdida de alimentación eléctrica o conexión de red, durante su procesamiento.
  • Se debe detectar la completitud de la réplica de las bases de datos, en caso de que el sistema incluya la replicación de datos.
  • Se debe evitar un fallo total cuando la concurrencia de usuarios supera la capacidad de respuesta.
  • Se deben manejar los errores de manera tal que no afecten el funcionamiento general.

Recuperabilidad

Para artefactos de tipo Portal Web y Sistema de Gestión:

  • Deben existir mecanismos que posibiliten el regreso a un punto estable, después de la ocurrencia de un fallo de cualquier tipo.

Disponibilidad

Para artefactos de tipo Portal Web y Sistema de Gestión:

  • Se debe realizar respaldo automático a las bases de datos.
  • Se debe garantizar la ejecución automatizada de los servicios y aplicaciones necesarios para una ejecución satisfactoria.

2

Primera conferencia sobre Calidad, Seguridad y Gestión normalizada de los servicios y productos de las Tecnologías Informáticas

En la mañana del día 02 de febrero se realizó la primera conferencia sobre Calidad, Seguridad y Gestión normalizada de los servicios y productos de las Tecnologías de la Información, en la sede de la ANEC. El encuentro fue propicio para que el presidente del Comité Técnico de Normalización No 18 (CTN 18), el Ing. José Manuel Santos Alonso hiciera una breve explicación del funcionamiento de comité así como de los tres subcomité que lo integran, el 7 de ingeniería de software, el 27 de seguridad informática y el 40 de gestión de servicio y gobernanza.

El presidente del SC40 Guillermo Wood Fonseca, enfatizó en la importancia que tiene vincular todos los conocimientos para formar a los directivos de los organizaciones productoras de software, así como los auditores de los sistemas de gestión.

La actividad central estuvo a cargo del MsC. Yoandy Lazo Alvarado, presidente del SC7, quien impartió una conferencia sobre la calidad de software.

 20170202

20170203

Entre los puntos tratados en la conferencia estuvo la evolución de la calidad.

1

Un análisis de los estándares utilizados en 17 organizaciones desarrolladoras de software en Cuba

2

Un análisis de las normas adoptadas por la ISO sobre la temática de Ingeniería de Software.

3

Un análisis de las normas adoptadas en Cuba sobre la temática de Ingeniería de Software y su actualidad comparadas con las aprobadas por la ISO.

4

Se expusieron los objetivos y metas del SC7, los principales resultados alcanzados y los proyectos de normas propuestos para el 2017.

Durante la conferencia también se analizaron dos normas que tributan a la calidad de los software, la primera relacionada con la calidad del producto (NC ISO/IEC 25010:2016) y la segunda una de los proyectos de normas que se trabaja durante el presente año, el Modelo de calidad para el Desarrollo de Aplicaciones Informáticas (MCDAI).

5

Al finalizar la conferencia se patentizó el compromiso de los organizadores de mantener el espacio para debatir sobre otros temas que potencien el desarrollo de las TI en Cuba.

NC ISO/IEC 25041:2017 SQuaRE – Guía de Evaluación para Desarrolladores, Adquirientes y Evaluadores independientes

El SC7 – Ingeniería de Software aprueba el proyecto de NC ISO/IEC 25041:2017 Ingeniería de Software y Sistemas – SQuaRE – Guía de Evaluación para Desarrolladores, Adquirientes y Evaluadores independientes, para su adopción en Cuba.

La NC ISO/IEC 25041 propone una serie de requisitos y recomendaciones para el proceso de evaluación de los desarrolladores, adquirientes o evaluadores independientes.

A continuación, se exponen organizado los requisitos por cada una de las etapas del proceso de evaluación que propone la NC ISO/IEC 25040.

Establecer los requisitos de la evaluación

Debe documentarse el propósito de la evaluación basado en el papel de los desarrolladores como base para las siguientes actividades y tareas de evaluación.

Deben identificarse las partes interesadas del desarrollo del producto.

Los requisitos de la calidad deberían definirse en términos de características y subcaracterísticas de la calidad (véase la NC ISO/IEC 25010) y la especificación de los requisitos de la calidad del producto deben ser presentados de la siguiente manera:

  • en el caso de la evaluación de los documentos de diseño, los requisitos deberían definirse mediante el uso de medidas de la calidad externa y/o medidas de la calidad en el uso;
  • en el caso de la evaluación de los productos intermedios, los requisitos deberían definirse mediante el uso de medidas de la calidad interna;
  • en el caso de la evaluación de los productos entregables, los requisitos deberían definirse mediante el uso de medidas de la calidad externa y/o medidas de la calidad en el uso.

Debe definirse la medida en que la evaluación de la calidad cubre los requisitos de la calidad del software especificados, teniendo en cuenta los requisitos de la calidad del producto, con el fin de especificar los requisitos de la evaluación de la calidad del producto.

Deben identificarse y documentarse las partes del producto a evaluarse basado en el propósito de la evaluación de la calidad del producto.

Debe definirse el rigor de la evaluación para cada parte del producto basado en la especificación de los requisitos de la calidad del producto.

  • En el caso de la evaluación de la especificación de requisitos durante la etapa de revisión del diseño, el rigor de la evaluación debe definirse para cada característica de la calidad del producto y para cada característica de la calidad en el uso desde la vista externa.
  • En el caso de la evaluación de los productos intermedios durante la etapa de implementación, el rigor de la evaluación debe definirse para cada característica de la calidad del producto desde la vista interna.
  • En el caso de la evaluación de la calidad de los productos entregables durante la etapa de pruebas unitarias, el rigor de la evaluación debe definirse para cada característica de la calidad del producto desde la vista interna.
  • En el caso de la evaluación de los productos entregables durante la creación de prototipos o la fase de pruebas de integración del sistema, el rigor de la evaluación debe definirse para cada característica de la calidad del producto y para cada característica de la calidad en el uso desde la vista externa.

Especificar la evaluación

Los evaluadores deben seleccionar las medidas de la calidad (módulos de evaluación) para cubrir todos los requisitos de la evaluación de la calidad del producto de software.

Las medidas de la calidad del producto para cada parte del producto a evaluarse deben definirse basado en el propósito de la evaluación de la calidad.

  • En el caso de la evaluación de la especificación de requisitos durante la etapa de revisión del diseño, las medidas de la calidad deben seleccionarse del conjunto de medidas de la calidad externas y medidas de la calidad en el uso.
  • En el caso de la evaluación de los productos intermedios durante la etapa de implementación, las medidas de la calidad deben seleccionarse del conjunto de medidas de la calidad internas.
  • En el caso de la evaluación de la calidad de los productos entregables intermedios durante la etapa de pruebas unitarias, las medidas de la calidad deben seleccionarse del conjunto de medidas de la calidad internas.
  • En el caso de la evaluación de los productos entregables durante la etapa de pruebas de integración del sistema, las medidas de la calidad deben seleccionarse del conjunto de medidas de la calidad externas y medidas de la calidad en el uso.

Los métodos de evaluación de la calidad del producto deben documentarse, teniendo en cuenta las actividades a realizarse con el fin de lograr los resultados de la evaluación. Cuando dichos métodos son basados en el uso de una herramienta de software, la herramienta debe identificarse en el plan de evaluación. Dicha identificación debe incluir al menos el nombre de la herramienta, la identificación de la versión y sus orígenes (por ejemplo, los proveedores, los desarrolladores).

La descripción de los métodos de evaluación debe completarse con la identificación de los componentes del producto en el que los métodos han de aplicarse.

Cuando se especifique la evaluación, se requiere un análisis experto de la medición con el fin de interpretar los resultados, debe especificarse el procedimiento de interpretación.

La especificación de evaluación debe comprender lo siguiente:

  • alcance de la evaluación refiriéndose a los componentes del producto identificados en la descripción del producto;
  • referencias cruzadas entre la información necesaria para realizar la evaluación y los componentes del producto y otros documentos mencionados en la descripción del producto;
  • especificación de las mediciones y verificaciones a realizarse y las referencias a los componentes del producto;
  • comparación entre la especificación de las mediciones y verificaciones y los requisitos de la evaluación, con referencia a las normas o la justificación de cada medición o verificación.

Los evaluadores deben definir un conjunto de medidas internas de las propiedades del software que:

  • cubran todos los productos y actividades intermedios correspondientes,
  • sean apropiadas para el dominio de aplicación y para el método a utilizarse en el desarrollo,
  • cubran los riesgos identificados del producto y el desarrollo. Ejemplos de los riesgos de desarrollo incluyen especificaciones inestables, problemas identificados no resueltos, y calendario atrasado, entre otros.

Los evaluadores deben definir el conjunto de medidas internas a las propiedades del software que se relacionan con las medidas externas de las propiedades del software, o se correspondan a los requisitos de la calidad.

Los evaluadores deben describir el modelo predictivo para el indicador de la calidad definido; es decir, la relación entre los indicadores y las medidas externas de las propiedades del software.

Los evaluadores deben definir las condiciones bajo las cuales la medición ha de realizarse.

Para cada medida de la calidad seleccionada deben definirse los criterios de decisión, para comparar los valores medidos de cada característica o subcaracterística de la calidad con los niveles de clasificación.

El nivel clasificación de cada característica o subcaracterística de la calidad seleccionada del producto, debe determinarse mediante un valor medido para cada medida seleccionada utilizando la comparación definida.

  • En el caso de la evaluación de las especificaciones de requisitos mediante la revisión del diseño, los criterios de decisión para las medidas de la calidad deben definirse para cada característica de la calidad del producto y cada característica de la calidad en el uso.
  • En el caso de la evaluación del producto intermedio durante la etapa de implementación, los criterios de decisión para las medidas de la calidad deben definirse para las características de la calidad del producto.
  • En el caso de la evaluación del producto ejecutable intermedio durante la etapa de pruebas unitarias, los criterios de decisión para las medidas de la calidad deben definirse para las características de la calidad del producto.
  • En el caso de la evaluación del producto entregable durante la etapa de pruebas de integración del sistema, los criterios de decisión para las medidas de la calidad deben definirse para cada característica de la calidad del producto y cada característica de la calidad en el uso.

Los criterios de decisión para la evaluación del producto, mediante los resúmenes de la evaluación (medidas de la calidad) deben definirse basándose en los requisitos de la calidad del producto.

  • En el caso de la evaluación de las especificaciones de los requisitos mediante la revisión del diseño, los criterios de decisión para la evaluación de la calidad deben definirse para cada característica de la calidad del producto y cada característica de la calidad en el uso.
  • En el caso de la evaluación del producto intermedio durante la etapa de implementación, los criterios de decisión para la evaluación de la calidad deben definirse para las características de la calidad del producto.
  • En el caso de la evaluación del producto intermedio durante la etapa de pruebas unitarias, los criterios de decisión para la evaluación de la calidad deben definirse para cada característica y subcaracterísticas de la calidad del producto.
  • En el caso de la evaluación del producto entregable durante la etapa de pruebas de integración del sistema, los criterios de decisión para la evaluación de la calidad deben definirse para cada característica de la calidad del producto y cada característica de la calidad en el uso.

Diseñar la evaluación

Las actividades de evaluación de la calidad de los productos identificados deben ser planificadas, teniendo en cuenta la disponibilidad de recursos tales como personal, herramientas de software y computadoras.

La actividad de evaluación de la calidad debe realizarse en el tiempo establecido durante la etapa del ciclo de vida de desarrollo del software.

El plan de evaluación debe incluir el propósito de la evaluación.

Durante las primeras etapas de la evaluación, algunos de los elementos del plan de evaluación pueden sólo definirse en un nivel alto. Por lo tanto, el plan de evaluación debe revisarse mientras las actividades de evaluación evolucionan, proporcionando información adicional, lo que permite al plan ajustarse o detallarse.

Los desarrolladores deben definir en cuáles actividades y procesos del ciclo de vida la medición y la evaluación de las propiedades de los productos serán implementadas. La medición y evaluación de las propiedades internas normalmente se llevará a cabo durante el proceso de desarrollo.

Los desarrolladores deben considerar cualquier influencia sobre las actividades de desarrollo de software. El conjunto de mediciones puede implicar un cambio en el proceso de desarrollo, a través de su necesidad de adquisición de datos.

Los desarrolladores deben definir acciones de contingencia, al igual que la evaluación adicional, si los resultados de la medición son alarmantes o no concluyentes.

Ejecutar la evaluación

Los problemas detectados de la calidad del producto deben resolverse en las etapas más tempranas posibles del desarrollo con el fin de evitar que queden problemas para futuras etapas y obtener así una mejora efectiva de la calidad del producto y la productividad del desarrollo.

De acuerdo con el plan de evaluación, las medidas de la calidad del producto seleccionadas deben aplicarse a los productos y componentes, lo que da lugar a los valores correspondientes a las escalas de medición.

En el control y monitoreo de la calidad que se lleva a cabo durante el desarrollo, los valores reales de las propiedades internas son recogidos. En caso de valores no deseados, la causa es analizada, lo que permite a los desarrolladores comprender y reaccionar ante los problemas.

Los desarrolladores deben recoger los valores de medición reales de las propiedades internas definidas, de acuerdo a las acciones de recolección de datos establecidas. Si los requisitos de la calidad del producto son cambiados, los desarrolladores deben reconsiderar la especificación y el diseño de la evaluación.

Los criterios de decisión para las medidas de la calidad del producto basados en los requisitos de la calidad deben aplicarse a los valores medidos, con el fin de evaluar los productos estáticos y dinámicos (por ejemplo, especificación de requisitos, diagramas de diseño y documento de prueba, producto ejecutable) durante el ciclo de vida de desarrollo del software.

  • En el caso de la evaluación de las especificaciones de requisitos durante la etapa de revisión del diseño, los criterios de decisión para las medidas de la calidad deben aplicarse a los valores medidos para cada característica de la calidad del producto y de la calidad en el uso.
  • En el caso de la evaluación de los productos intermedios estáticos, los criterios de decisión para las medidas de la calidad deben aplicarse a los valores medidos para las características de la calidad del producto.
  • En el caso de la evaluación del producto entregable dinámico, los criterios de decisión para las medidas de la calidad deben aplicarse a los valores medidos para cada característica de la calidad del producto y de la calidad en el uso.

Los criterios de decisión para la evaluación de la calidad del producto basados en los requisitos de la calidad deben aplicarse al resultado de los valores obtenidos mediante el uso de las características y subcaracterísticas de la calidad, con el fin de evaluar los productos estáticos y dinámicos (por ejemplo, especificación de requisitos, diagramas de diseño y documento de prueba y producto ejecutable) durante el ciclo de vida de desarrollo del software.

El conjunto de criterios de decisión debe resumirse en características y subcaracterísticas, produciendo los resultados a evaluar como una declaración de la medida en la que el producto cumple con los requisitos de la calidad.

Concluir la evaluación

Los evaluadores y los solicitantes deben llevar a cabo un análisis conjunto de los resultados de la evaluación.

El grupo de evaluadores debe revisar los resultados de la evaluación de los productos entregables estáticos (por ejemplo, especificación de requisitos, diagramas de diseño y documento de prueba).

El grupo de evaluadores debe revisar los resultados de la evaluación y la validez del proceso de evaluación, los indicadores y las medidas aplicadas. La retroalimentación de la revisión debería utilizarse con el fin de mejorar el proceso y las técnicas de evaluación (módulos de evaluación).

Los resultados de la evaluación de la calidad deben ser revisados con el fin de asegurar la calidad del informe de evaluación de la calidad.

Los desarrolladores deben hacer que los datos recogidos a disposición de la organización se usen en otro proyecto de evaluación.

Los evaluadores deben revisar los resultados de la evaluación y la validez del proceso de evaluación, indicadores y medidas aplicadas.

Cuando se concluye la evaluación, los datos y los elementos de la evaluación, deben disponerse de acuerdo con los requisitos de los solicitantes.

Esto debe hacerse de una de las siguientes maneras, dependiendo del tipo de dato:

  • los documentos presentados a la evaluación deben devolverse a los solicitantes o archivarse durante un tiempo especificado o destruirse de manera segura;
  • el informe de evaluación y los registros de evaluación deben archivarse durante un tiempo determinado;
  • todos los demás datos deben archivarse durante un tiempo determinado o destruirse de manera segura.

Cuando para algunos datos expira la duración de archivado especificada, debe archivarse nuevamente durante un tiempo determinado o destruirse de manera segura.