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.

Subcomité 7: un año de resultados

Efectuado balance del SC7 correspondiente al año 2016.

Por: Yasmani Pérez Forteza estudiante de Periodismo.

DSC_0010

Con la finalidad de realizar un análisis del trabajo realizado en el año que termina y conciliar las metas para el 2017 los integrantes del Subcomité 7- Ingeniería de Software (SC7) efectuaron un balance en la sede del Centro Nacional de Calidad de Software (CALISOFT).

Dentro de los resultados más sobresalientes del periodo destacan la aprobación y entrega a la Oficina Nacional de Normalización (ONN) de proyectos de normas cubanas para su posterior adopción como la ISO/IEC 25010:2011, la ISO/IEC 25020:2007 y la ISO/IEC 25040:2011, las cuales dentro de los Requisitos de la Calidad y Evaluación de Software (SQuaRE), contemplan los Modelos de la Calidad de Software y Sistemas, el Modelo de Referencia y Guía para las Mediciones y el Proceso de Evaluación.

Además, reconocieron el comienzo de revisión de la ISO/IEC 25041:2012, la que constituiría la Guía de Evaluación para Desarrolladores, Adquirientes y Evaluadores Independientes, y del proyecto de Norma Ramal – Requisitos de la Calidad para Sistemas Informáticos y Productos de Software.

El Presidente del subcomité 7 – Ingeniería de Software (SC7), Yoandy Lazo Alvarado, expuso que era necesario incorporar más expertos y otras entidades relacionadas con la enseñanza de la ingeniería y el desarrollo de software al trabajo del subcomité y que se debe adoptar medidas para lograr eso objetivo.

Los participantes propusieron aumentar la divulgación del trabajo del SC7 para buscar un mayor impacto en el desarrollo de la industria cubana del software y patentizaron su compromiso de trabajar en función de la implementación de los Lineamientos de la Política Económica y Social del Partido y la Revolución y la Política de Informatización de la Sociedad del país.

Durante la reunión de balance se realizó la presentación de las metas para el venidero año, donde están la entrega a la ONN para su adopción en Cuba de varias normas como: las ISO/IEC 25041:2012 (Guía de Evaluación para Desarrolladores, Adquirientes y Evaluadores Independientes); ISO/IEC 25030:2007 (Requisitos de la Calidad), ISO/IEC 25001:2014 (Planificación y gestión); y la Norma Ramal Requisitos de la Calidad para Sistemas Informáticos y Productos de Software.

Los integrantes del Subcomité 7- Ingeniería de Software (SC7) son expertos técnicos que pertenecen a CALISOFT y algunas empresas como la de Tecnologías de la Información para la Defensa (XETID), la de Consultoría y Seguridad Informática (SEGURMÁTICA), la de Tecnologías y Servicios Telemáticos Avanzados (CITMATEL), el Grupo Empresarial de la Informática y las Comunicaciones (GEIC), la Unidad Adscrita de Servicios Informáticos (UASI) del Banco Central de Cuba, la UEB de Informática de la Empresa de Informática y Automatización para la Construcción (AICROS) y la división DATAZUCAR de la Empresa de Servicios Técnicos Industriales (ZETI).

DSC_0012

La calidad transforma

Con el lema “LA CALIDAD TRANSFORMA” los integrantes del subcomité 7 – Ingeniería de software celebraron el Día Mundial de la CALIDAD.

DSC_0748

DSC_0747

Los segundos jueves del mes de noviembre se celebra el Día Mundial de la Calidad, promulgado por la Organización de Naciones Unidas (ONU) en 1990 con el objetivo de aumentar la conciencia mundial sobre la importancia de la Calidad en el aseguramiento de la prosperidad de las naciones.

El Día Mundial de la Calidad se centra en la visión de una calidad que impulsa, ordena y gestiona la transformación de las personas y las organizaciones.

La calidad brinda satisfacción a los consumidores de un servicio o un producto determinado, de ahí que esté presente en todos los momentos de la vida cotidiana. La industria de software no es la excepción, y su capacidad trasformadora actúa en los clientes, los profesionales del ramo y la dirección, incidiendo en la innovación, gestión de los proyectos, gestión de riesgos, gestión de adquisiciones, gestión de la configuración, ingeniería de requisitos y desarrollo del software.

La disciplina de la calidad es diversa, abierta y está en permanente estado de transformación, se basa en los siguientes principios:

  • Calidad es iniciativa. La calidad trasforma a las personas y a las organizaciones para conectar, de manera sencilla y eficiente, estrategia y negocio.
  • Calidad es interacción. La calidad sitúa al cliente en el centro de las organizaciones y materializa el compromiso y la responsabilidad de las empresas y sus profesionales con la sociedad.
  • Calidad es información. La calidad aporta a la dirección indicadores que simplifican y hacen eficiente el negocio, fortaleciendo su competitividad y sostenibilidad.
  • Calidad es inteligencia. La calidad ofrece un lenguaje común para aprender, compartir, analizar e integrar los datos del entorno en sus sistemas y procesos de gestión.
  • Calidad es innovación. La calidad es abierta, multidisciplinaria, colaborativa, creativa, y en permanente evolución, responde a los retos que plantea el nuevo contexto económico, social y tecnológico.
  • Calidad es inspiración. La calidad crea y ofrece valor tangible a las organizaciones y a la sociedad y es capaz de dar nuevas soluciones a nuevos problemas.

Fuentes consultadas

  • http://www.diarioinformacion.com/especiales/dia-mundial-calidad/2016/11/calidad-transformador-n1163_1_33945.html