Garantía de Calidad Estadística

Definición

La garantía de calidad estadística refleja una tendencia, creciente en toda la industria, a establecer la calidad más cuantitativamente. Para el software, la garantía de calidad estadística implica los siguientes pasos:

  1. Se agrupa y se clasifica la información sobre los defectos del software.
  2. Se intenta encontrar la causa subyacente de cada defecto (por ejemplo, no concordancia con la especificación, error de diseño, incumplimiento de los estándares, pobre comunicación con el cliente).
  3. Mediante el principio de Pareto (el 80 por 100 de los defectos se pueden encontrar en el 20 por 100 de todas las posibles causas), se aísla el 20 por 100 (los «POCOS vitales»).
  4. Una vez que se han identificado los defectos vitales, se actúa para corregir los problemas que han producido los defectos.

Este concepto relativamente sencillo representa un paso importante hacia la creación de un proceso de ingeniería del software adaptativo en el cual se realizan cambios para mejorar aquellos elementos del proceso que introducen errores.

Ejemplo

Para ilustrar el proceso, supongamos que una organización de desarrollo de software recoge información sobre defectos durante un período de un año. Algunos de los defectos se descubren mientras se desarrolla el software. Otros se encuentran después de que el software se haya distribuido al usuario final. Aunque se descubren cientos de errores diferentes, todos se pueden encontrar en una (o más) de las siguientes causas:

  • Especificación incompleta o errónea (EIE).
  • Mala interpretación de la comunicación del cliente (MCC).
  • Desviación deliberada de la especificación (DDE).
  • Incumplimiento de los estándares de programación (IEP).
  • Error en la representación de los datos (ERD).
  • Interfaz de módulo inconsistente (IMI).
  • Error en la lógica de diseño (ELD).
  • Prueba incompleta o errónea (PIE).
  • Documentación imprecisa o incompleta (DII).
  • Error en la traducción del diseño al lenguaje de programación (TLP).
  • Interfaz hombre-máquina ambigua o inconsistente (IHM).
  • Varios (VAR).

Para aplicar la SQA estadística se construye la una tabla. La tabla indica que EIE, MCC y ERD son las causas vitales que contabilizan el 53 por 100 de todos los errores. Sin embargo, debe observarse que si sólo se consideraran errores serios, se seleccionarían las siguientes causas vitales: EIE, ERD, TLP y ELD. Una vez determinadas las causas vitales, la organización de desarrollo de software puede comenzar la acción correctiva. Por ejemplo, para corregir la MCC, el equipo de desarrollo del software podría implementar técnicas que facilitaran la especificación de la aplicación para
mejorar la calidad de la especificación y la comunicación con el cliente. Para mejorar el ERD, el equipo de desarrollo del software podría adquirir herramientas CASE para la modelización de datos y realizar revisiones del diseño de datos más rigurosas. Es importante destacar que la acción correctiva se centra principalmente en las causas vitales. Cuando éstas son corregidas, nuevas candidatas saltan al principio de la lista. Se han mostrado las técnicas de garantía de calidad del software estadísticas para proporcionar una mejora sustancial en la calidad. En algunos casos, las
organizaciones de software han conseguido una reducción anual del 50 por 100 de los errores después de la aplicación de estas técnicas. Junto con la recopilación de información sobre defectos, los equipos de desarrollo del software pueden calcular un indice de errores (IE) para cada etapa principal del proceso de ingeniería del software. Después
del análisis, el diseño, la codificación, la prueba y la entrega, se recopilan los siguientes datos:
Ei = número total de defectos descubiertos durante la etapa i-ésima del proceso de ingeniería del software;
Si = número de defectos graves;
Mi =número de defectos moderados;
Ti = número de defectos leves;
PS =tamaño del producto (LDC, sentencias de diseño, páginas de documentación) en la etapa i-ésima.
Ws, W,,, , Wt = factores de peso de errores graves, moderados, y leves, en donde los valores recomendados son Ws=10,Wm=3,W,=1. Los factores de peso de cada fase deberían agrandarse a medida que el desarrollo evoluciona. Esto favorece a la organización que encuentra los errores al principio.

En cada etapa del proceso de ingeniería del software se calcula un índice de fase, IFi:

IFi=Ws(Si/Ei)+Wm(MiiEi)+Wt(Ti/Ei)

El indice de errores (IE) se obtiene mediante el cálculo del defecto acumulativo de cada IFi, asignando más peso a los errores encontrados más tarde en el proceso de ingeniería del software, que a los que se encuentran en las primeras etapas:

IE = Σ(i x IF,) / PS = (IF, + 2IF2 + 3IF3 + … iIFi) / PS

Se puede utilizar el índice de errores junto con la información recogida en la tabla, para desarrollar una indicación global de la mejora en la calidad del software. La aplicación de la SQA estadística y el principio de Pareto se pueden resumir en una sola frase: Utilizar el tiempo para centrarse en cosas que realmente interesan, pero primero asegurarse que se entiende qué es lo que realmente interesa.

Bilbiografía:

PRESSMAN Roger, “Ingeniería del Software. Un Enfoque Práctico”, Quinta Edición, Mc Graw Hill, 2002

Anuncios

Tendencia de la Calidad y Garantía de la Calidad de Software

Tendencia de la Calidad

Comenzó en los años 40 con el trabajo de W. Edwars Deming, se hizo la primera verificación en Japón para la eliminación de las causas raíz de defectos de productos. En los años 80 emigro al mundo occidental y se llama Gestión Total de la Calidad (GTC). Se encuentra una progresión básica de 4 pasos:

1. Kuizen: Sistema de mejora continua del proceso y su objetivo es desarrollar un proceso que sea visible, repetible y mesurable.

2. Aturimae hinshitsu: Examina lo intangible que afecta al proceso y trabaja para optimizar su impacto en el mismo.

3. Kansei: Se centra en el usuario del producto, en esencia examina la forma en que el usuario del producto.

4. Miryokuteki hinshitsu: Orientado a la gestión que busca la oportunidad en áreas relacionadas que se pueden identificar observando la utilización del producto en el mercado. En Software sería  un intento de detectar productos nuevos y beneficios, o aplicaciones que sean una extensión de un sistema ya existente basado en computadora.

Garantía de la Calidad de Software

La calidad de software  se definen como: “Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente”.

Problemas de fondo

En los años 50 y 60 la calidad era responsabilidad del programador.

En los setenta se introdujeron estándares de calidad para software en los contratos militares y se ha extendido rápidamente en el software de tipo comercial.

La calidad es la primera tarea, todos tiene responsabilidad de la garantía de la calidad de software. El Grupo de SQA sirve como representación del cliente es decir mirar al software desde el punto de vista del cliente.

Actividades del SQA

Comprende una gran variedad de tareas asociadas con 2 constitutivos diferentes: Los ingenieros de software que realizan el trabajo técnico y el Grupo de SQA que tiene la responsabilidad de la planificación de la garantía de la calidad, supervisión, mantenimiento de registros, análisis e informes.

El grupo de SQA trata de ayudar al grupo de ingeniería de software en la consecución de un producto de calidad. Llevan a cabo las siguientes actividades:

  1. Establecimiento de un Plan de SQA para un proyecto: Se desarrolla durante la planificación del proyecto y es revisado por las partes interesadas  comprende:
  2. Participación en el desarrollo de la descripción del proceso de software del  proyecto: El equipo de ingenieros del software selecciona un proceso para el trabajo que se va e realizar y el grupo de SQA revisa la descripción del proceso para ajustarse a las políticas de la empresa, estándares internos de software e impuestos externamente.
  3. Revisión de las actividades de ingeniería del software para verificar su ajuste al proceso de software definido: El grupo de SQA identifica, documenta y sigue la pista de las desviaciones desde el proceso y verifica que se han hecho las correcciones.
  4. Auditoria de los productos de software designados para verificar el ajuste con los definidos  como parte del proceso de software: Las desviaciones se pueden encontrar en el plan del proyecto, en la descripción del proceso, en los estándares aplicados o en los productos técnicos.
  5. Registrar lo que no se ajuste a los requisitos e informar a sus superiores: Los elementos   no se ajustan a los requisitos están bajo seguimiento hasta que se resuelven.

Además de estas actividades el grupo de SQA coordina el control y la gestión de cambios y ayuda a recopilar y a analizar las métricas del software.

Estándar de Calidad ISO 9001 en Software

El estándar, que ha sido adoptado por más de 130 países para su uso, se está convirtiendo en el medio principal con el que los clientes pueden juzgar la competencia de un desarrollador de software. Uno de los problemas con el estándar ISO 9001 está en que no es específico de la industria: está expresado en términos generales, y puede ser interpretado por los desarrolladores de diversos productos como cojinetes de bolas, secadores de pelo, automóviles, equipamiento deportivo, televisores, así como por los desarrolladores de software. Se han realzado muchos documentos que relacionan el estándar con la industria del software, pero no entran en una gran cantidad de detalles.

Para la industria del software los estándares relevantes son:

•  ISO 9001: este es un estándar que describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño.

•  ISO 9000-3: este es un documento específico que interpreta el ISO 9001 para el desarrollador de software.

•  ISO 9004-2: este documento proporciona las directrices para el servicio de facilidades del software como soporte de usuarios.

Los requisitos se agrupan bajo 20 títulos:

•  Responsabilidad de la gestión

•  Inspección, medición y equipo de pruebas

•  Sistema de calidad

•  Inspección y estado de pruebas

•  Revisión de contrato

•  Acción correctiva

•  Control de diseño

•  Control de producto no aceptado

•  Control de documento

•  Tratamiento, almacenamiento, empaquetamiento y entrega

•  Compras

•  Producto proporcionado al comprador

•  Registros de calidad

•  Identificación y posibilidad de seguimiento del producto

•  Auditorias internas de calidad

•  Formación

•  Control del proceso

•  Servicios

•  Inspección y estado de pruebas

•  Técnicas estadísticas.

Pruebas de Software

Pruebas de Software a ejercicio de COCOMO:

Link COCOMO BÁSICO

Caja negra. No esta basada en el conocimiento del código o diseño interno,determina la funcionalidad del sistema.

Caso de prueba Cálculo de estimación de costos mediante COCOMO Básico
Propósito Obtener esfuerzo, tiempo de duración y número de personas de un proyecto orgánico, semiacoplado o empotrado mediante COCOMO básico.
Prerrequisitos Iniciar la aplicación
Datos de entrada Número de líneas de código (KLDC)

Tipo de Proyecto: orgánico, semiacoplado o empotrado.

Pasos
  1. Introducir número de líneas de código
  2. Seleccionar el tipo de proyecto
  3. Hacer clic en calcular
Resultado esperado El programa muestra los resultados de los cálculos

  • Esfuerzo hombre – mes
  • Duración meses
  • Personas estimadas personas

Caja blanca. Esta basada en la lógica interna de la aplicacion y el código. Hace una cobertura de declaraciones del código, ramas, caminos y condiciones.

 

 public Cocomo(String tipo,double kldc){
 this.setKldc(kldc);
 if(tipo.equals("Orgánico")){
 this.setTipo("Orgánico");
 this.setA(2.4);
 this.setB(1.05);
 this.setC(2.5);
 this.setD(0.38);
 }
 if(tipo.equals("Semiacoplado")){
 this.setTipo("Semiacoplado");
 this.setA(3.0);
 this.setB(1.12);
 this.setC(2.5);
 this.setD(0.35);
 }
 if(tipo.equals("Empotrado")){
 this.setTipo("Empotrado");
 this.setA(3.6);
 this.setB(1.20);
 this.setC(2.5);
 this.setD(0.32);
 }
 calcular();
 }
<code> 


 

Integración incremental. Cuando nuevas funciones son ingresadas al sistema se hace la prueba basándose en la funcionalidad, la dependencia con otros módulos y la integración con el programa completo. NO APLICABLE PUESTO QUE ES UNA APLICACIÓN QUE NO REQUIERE DE MÁS MÓDULOS

Prueba de integración. Se basa en las pruebas de conexiones y comunicaciones entre diferentes módulos. Es esencial en sistemas de cliente_servidor o red. NO APLICABLE PUESTO QUE ES UNA APLICACIÓN DE ESCRITORIO

Prueba de fin a fin. Es similar a la prueba de sistema pero esta involucra la interacción con otros hardwares, bases de datos y redes. NO APLICABLE PORQUE NO REQUIERE DE BASES DE DATOS NI HARDWARE ADICIONAL

Prueba de sanidad. Determina si la nueva versión de un software esta bien realizada y si necesita un nuevo esfuerzo en la prueba de software. Por ejemplo la nueva versión de un programa cumple con casi todos los requisitos pero destruye la base de datos al leerla, por lo tanto se dice que este software no esta en una condición sana.

Luego del análisis se requiere adicionar nuevos requerimientos como agregar al software la posibilidad de agregar estimaciones de manera intermedia y avanzada, y no solo básico.

Calidad del Software

  • Conceptos de Calidad

En una versión sucinta la calidad en la ingeniería del software es un grupo de características que representa la efectividad y la eficiencia de un sistema de información.

Es importante enfatizar en dos puntos :

  • Un software de calidad debe ser eficaz, es decir, que debe realizar las funciones establecidas, debe ser amigable. Un usuario debe utilizar el software porque produce resultados confiables, realiza todas las operaciones que se requieren, ejecuta las operaciones en un tiempo aceptado y es fácilmente usado por el grupo de usuarios a quien este dirigido.
  • Un software de calidad debe ser eficiente, es decir el costo de su desarrollo tomando todos los recursos y el costo de su operación debe ser tal que las organizaciones involucradas en su desarrollo y uso obtengan el máximo beneficio o por lo menos un beneficio aceptable en un período de tiempo establecido.

Para ilustrar el concepto de calidad de manera más profunda, es necesario considerar algunos aspectos fundamentales que caracterizan al software de calidad como son : solidez, exactitud, completitud, mantenibilidad, reutilizabilidad, claridad en la documentación, entre otros.

  • La tendencia de la calidad

Empezó en los años cuarenta con W. Edwards Deming y se hizo la primera verificación en Japón.
Hay 4 Pasos que son la esencia de cualquier software (Gestión Total de Calidad).

  1. Kuizen y se refiere a un sistema de mejora continua del proceso. Su prioridad es desarrollar un proceso que sea visible, repetible y medible.
  2. Aturimaehinshitsu es invocado sólo una vez, en este paso examina lo intangible que afecta al proceso y trabaja para optimizar su impacto en el proceso.
  3. Kansei el centro aquí es el usuario del producto, examina la forma de como el usuario aplica el producto.
  4. Miryokutekihinshitsu amplía la preocupación de la gestión más allá del producto inmediato.
  • Garantía de calidad del software

Garantía de calidad del software (SQA) consiste en los medios de la supervisión tecnología de dotación lógica los procesos y los métodos aseguraban calidad. Hace esto por medio de intervenciones de sistema de gerencia de la calidad debajo de cuál se crea el sistema de software. Estas intervenciones son movidas hacia atrás por unos o más estándares, generalmente ISO 9000.

Es distinto de control de calidad del software cuál incluye el repaso requisitos documentos, y prueba del software. La SQA abarca el entero desarrollo del software proceso, tales como el cual incluye procesos diseño del software, codificación, control del código de fuente, revisiones de código, cambie a gerencia, gerencia de la configuración, y lance a gerencia. Mientras que el control de calidad del software es un control de productos, la garantía de calidad del software es un control de procesos.

La garantía de calidad del software se relaciona con la práctica de garantía de calidad en producto fabricación. Hay, sin embargo, algunas diferencias notables entre el software y un producto manufacturado. Estas diferencias provienen el hecho de que el producto manufacturado es físico y puede ser visto mientras que el producto de software no es visible. Por lo tanto su función, ventaja y costes no están según lo medido fácilmente. Cuál es más, cuando un producto manufacturado cae la planta de fabricación, es esencialmente un completo, producto final, mientras que el software nunca se acaba. El software vive, crece, se desarrolla, y transforma, desemejante de sus contrapartes tangibles. Por lo tanto, los procesos y los métodos para manejar, para supervisar, y para medir su calidad en curso son tan líquido y a veces evasivos como son los defectos que se significan para mantener cheque.

  • Revisiones del software

Es “un proceso o una reunión durante los cuales un producto de software es [examinado cerca] personal del proyecto, encargados, usuarios, clientes, representantes del usuario, u otros partidos interesados para el comentario o la aprobación”.

En este contexto, los medios “producto de software” del término del “cualquier documento técnico o documento parcial, elaborado como entregable de una actividad del desarrollo del software”, y pueden incluir documentos tales como contratos, los planes y los presupuestos del proyecto, los documentos de los requisitos, las especificaciones, los diseños, código de fuente, documentación del usuario, documentación de la ayuda y de mantenimiento, los planes de prueba, las especificaciones de prueba, los estándares, y cualquier otro tipo de producto del trabajo del especialista.

  • Revisiones técnicas formales

Las revisiones formales tienen tres elementos:

  • Informe escrito del estado del producto revisado.
  • La participación activa y abierta de todos los del grupo de revisión.
  • Total responsabilidad de todos los participantes en la calidad de la revisión.

Objetivos:

  • Descubrir errores en la función, la lógica o la implementación de cualquier representación del software.
  • Verificar que el software bajo revisión alcanza sus requisitos.
  • Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos.
  • Conseguir un software desarrollado de forma uniforme.
  • Facilitar manejo de proyectos.
  • Fiabilidad del software

Si un programa falla frecuentemente en su funcionamiento, no importa si el resto de los factores de calidad son aceptables. Puede ser medida o estimada mediante datos históricos o de desarrollo.

La fiabilidad del software se define en términos estadísticos como la probabilidad de operación libre de fallos de un programa de computadora es un entorno determinado y durante un tiempo específico.

¿Qué se entiende por el término fallo? En el contexto de cualquier discusión sobre calidad y fiabilidad del software, el fallo es cualquier falla de concordancia con los requisitos del software.

En esta definición existen grados.

Los fallos pueden ser simplemente desconcertantes o ser catastróficos.

Puede que un fallo sea corregido en segundos mientras que otro lleve semanas o incluso meses. Para complicar más las cosas, la corrección de un fallo puede llevar a la introducción de otros errores que, finalmente, lleven a más fallos.

  • Prueba de errores para el software

Las pruebas de software, en inglés testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.

Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.

Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

  • El estándar de calidad ISO 9001

El estándar, que ha sido adoptado por más de 130 países para su uso, se está convirtiendo en el medio principal con el que los clientes pueden juzgar la competencia de un desarrollador de software. Uno de los problemas con el estándar ISO 9001 está en que no es específico de la industria: está expresado en términos generales, y puede ser interpretado por los desarrolladores de diversos productos como cojinetes de bolas, secadores de pelo, automóviles, equipamiento deportivo, televisores, así como por los desarrolladores de software. Se han realzado muchos documentos que relacionan el estándar con la industria del software, pero no entran en una gran cantidad de detalles.

Para la industria del software los estándares relevantes son:

•  ISO 9001: este es un estándar que describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño.

•  ISO 9000-3: este es un documento específico que interpreta el ISO 9001 para el desarrollador de software.

•  ISO 9004-2: este documento proporciona las directrices para el servicio de facilidades del software como soporte de usuarios.

Los requisitos se agrupan bajo 20 títulos:

•  Responsabilidad de la gestión

•  Inspección, medición y equipo de pruebas

•  Sistema de calidad

•  Inspección y estado de pruebas

•  Revisión de contrato

•  Acción correctiva

•  Control de diseño

•  Control de producto no aceptado

•  Control de documento

•  Tratamiento, almacenamiento, empaquetamiento y entrega

•  Compras

•  Producto proporcionado al comprador

•  Registros de calidad

•  Identificación y posibilidad de seguimiento del producto

•  Auditorias internas de calidad

•  Formación

•  Control del proceso

•  Servicios

•  Inspección y estado de pruebas

•  Técnicas estadísticas.

Análisis y Gestión de Riesgo

¿Qué es la identificación de un riesgo y cual es su clasificación?

La identificación y valoración de los riesgos permite:

  • Prevenir su ocurrencia, y cuando esto no es posible, desarrollar un plan de respaldo, “back-up” o de contingencia (Control proactivo), o
  • Modificar o minimizar la probabilidad de ocurrencia del riesgo, la calidad de las amenazas y, de ser posible, el impacto en el desempeño del proyecto (Control reactivo).

¿Cuál es la evaluación global del riesgo del proyecto, los componentes y controladores del riesgo?

El riesgo tiene tres componentes primarios:

  • Un evento, (un cambio no deseado),
  • Una probabilidad de ocurrencia de ese evento,
  • El Impacto de ese evento, (cantidad apostada o en riesgo).

¿Cómo se realiza la estimación del riesgo?

La estimación de riesgos describe cómo estudiar los riesgos dentro de la planeación general del entorno informático y se divide en los siguientes pasos:

  • La identificación de riesgos genera una lista de riesgos capaces de afectar el funcionamiento normal del entorno informático.
  • El análisis de riesgos mide su probabilidad de ocurrencia y su impacto en la organización.
  • La asignación de prioridades a los riesgos.

¿Cuales son los beneficios de realizar una estimación de riesgos?

El objetivo general del estimación de riesgos es identificar sus causas potenciales, los principales riesgos que amenazan el entorno informático. Esta estimación se realiza en una determinada área para que se pueda tener información suficiente al respecto, optando así por un adecuado diseño e implantación de mecanismos de control; a fin de minimizar los efectos de eventos no deseados, en los diferentes puntos de análisis.