Calidad

Tendencia de Calidad

Hoy en día los responsables expertos de compañías de todo el mundo industrializado reconocen que la alta calidad del producto se traduce en ahorro de coste y en una mejora general.
La tendencia de la calidad comenzó en los años cuarenta con el influyente trabajo de W. Edwards Deming [DEM86], y se hizo la primera verificación en Japón.
Mediante las ideas de Deming como piedra angular, los japoneses han desarrollado un enfoque sistemático para la eliminación de las causas raíz de defectos en productos.
A lo largo de los años setenta y ochenta, su trabajo emigró al mundo occidental y a veces se llama “gestión total de calidad (GTC) x2A. Aunque la terminología difiere según los diferentes países y autores, normalmente se encuentra una progresión básica de cuatro pasos que constituye el fundamento de cualquier programa de GTC.

“El enfoque GTC se centra en la mejora continua del proceso”.

El primer paso se llama kuizen y se refiere a un sistema de mejora continua del proceso. El objetivo de kuizen es desarrollar un proceso (en este caso, proceso del software) que sea visible, repetible y mensurable.

El segundo paso, invocado sólo una vez que se ha alcanzado kuizen, se llama Aturimae hinshitsu. Este paso examina lo intangible que afecta al proceso y trabaja para optimiza su impacto en el proceso. Puede ser que una estructura organizativa estable haga mucho para mejorar la calidad del software. Aturimae hinshitsu llevaría a la gestión a sugerir cambios en la forma en que ocurre la reorganización.

Mientras que los dos primeros pasos se centran en el proceso, el paso siguiente llamado kansei (traducido como “los cinco sentidos”) se centra en el usuario del producto (en este caso, software). En esencia, examinando la forma en que el usuario aplica el producto, kansei conduce a la mejora en el producto mismo, y potencialmente al proceso que lo creó.

Finalmente, un paso llamado miryokuteki hinshitsu amplía la preocupación de la gestión más allá del producto inmediato. Este es un paso 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 el mundo del software, miryokuteki hinshitsu se podría ver como un intento de detectar productos nuevos y beneficiosos, o aplicaciones que sean una extensión de un sistema ya existente basado en computadora.

Garantía de calidad del Software

Hasta el desarrollador de software más agobiado está de acuerdo con que el software de alta calidad es una meta importante. Pero, ¿cómo definimos la calidad? Un bromista dijo una vez: “Cualquier programa hace algo bien, lo que puede pasar es que no sea lo que nosotros queremos que haga”.

Calidad de software

Es la 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.

Según esta definición se plantean tres puntos importantes:

1. Los requisitos del software son la base de las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.
2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.
3. Existe un conjunto de requisitos implícitos que a menudo no se mencionan (por ejemplo: el deseo por facilitar el uso y un buen mantenimiento). Si el software se ajusta a sus requisitos explícitos pero falla en alcanzar los requisitos implícitos, la calidad del software queda en entredicho.

Problemas de fondo

La historia de la garantía de calidad en el desarrollo de software es paralela a la historia de la calidad en la creación de hardware. Durante los primeros años de la informática (los años cincuenta y sesenta), la calidad era responsabilidad únicamente del programador. Durante los años setenta se introdujeron estándares de garantía de calidad para el software en los contratos militares para desarrollo de software y se han extendido rápidamente a los desarrollos de software en el mundo comercial [IEE94]. Ampliando la definición presentada anteriormente, la garantía de calidad del software (SQA) es un “patrón de acciones planificado y sistemático” [SCH97] que se requiere para asegurar la calidad del software.

El grupo de SQA sirve como representación del cliente en casa. Es decir, la gente que lleva a cabo la SQA debe mirar el software desde el punto de vista del cliente.

Actividades de SQA

La garantía de calidad del software comprende una gran variedad de tareas, asociadas con dos constitutivos diferentes.

Los ingenieros de software que realizan trabajo técnico y un grupo de SQA que tiene la responsabilidad de la Planificación de garantía de calidad, supervisión, mantenimiento de registros, análisis e informes

Los ingenieros de software afrontan la calidad (y realizan garantía de calidad) aplicando métodos técnicos sólidos y medidas, realizando revisiones técnicas formales y llevando a cabo pruebas de software bien planificadas.

Las reglas del grupo de SQA tratan de ayudar al equipo de ingeniería del software en la consecución de un producto final de alta calidad. El Instituto de Ingeniería del
Software [PAU93] recomienda un conjunto de actividades de SQA que se enfrentan con la planificación de garantía de calidad, supervisión, mantenimiento de registros, análisis e informes. Éstas son las actividades que realizan o facilitan un grupo independiente de SQA:

Establecimiento de un plan de SQA para un proyecto.

El plan se desarrolla durante la planificación del proyecto y es revisado por todas las partes interesadas. Las actividades de garantía de calidad realizadas por el equipo de ingeniería del software y el grupo SQA son gobernadas por el plan. El plan identifica:

• evaluaciones a realizar,
• auditorías y revisiones a realizar,
• estándares que se pueden aplicar al proyecto,
• procedimientos para información y seguimiento de errores
• documentos producidos por el grupo SQA,
• realimentación de información proporcionada al equipo de proyecto del software.

Actividades de un grupo de SQA

Participación en el desarrollo de la descripción del proceso de software del proyecto. El equipo de ingeniería del software selecciona un proceso para el trabajo que se va a realizar. El grupo de SQA revisa la descripción del proceso para ajustarse a la política de la empresa, los estándares internos del software, los estándares impuestos externamente (por ejemplo: 1SO 9001), y a otras partes del plan de proyecto del software.

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.

Auditoría de los productos de software designados para verificar el ajuste con los definidos como parte del proceso del software. El grupo de SQA revisa los productos seleccionados; identifica, documenta y sigue la pista de las desviaciones; verifica que se han hecho las correcciones, e informa periódicamente de los resultados de su trabajo al gestor del proyecto.

Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido. Las desviaciones se pueden encontrar en el plan del proyecto, en la descripción del proceso, en los estándares aplicables o en los productos técnicos.

Registrar lo que no se ajuste a los requisitos e informar a sus superiores. Los elementos que no se ajustan a los requisitos están bajo seguimiento hasta que se resuelven.

WEBGRAFIA:

deming.eng.clemsom.edu/
www.management.gov