sábado, 15 de enero de 2011

GARANTIA DE CALIDAD DEL SOFTWARE (SQA/GCS)



La tendencia de la calidad
La tendencia de la calidad se ha utilizado desde los años cuarenta con el objetivo de obtener una alta calidad del producto tanto en ahorro de costes y en una mejora general, para ello se basa en la terminología de GTC (gestión de calidad total) normalmente se encuentra una progresión básica de cuatro pasos que constituye el fundamento de cualquier programa de GTC.
Los dos primeros pasos se centran en la mejora del proceso, el tercer paso se centra en el usuario del producto y finalmente el cuarto paso va más allá del producto se centra en la utilización del producto en el mercado.

Garantía de calidad del software
Para tener una garantía de calidad del software debe existir una concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo claramente documentados, y con las características implícitas que se espera de todo software desarrollado profesionalmente.

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.
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.
Muchas de las veces 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 no se logra.

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

Ampliando la definición presentada anteriormente, la garantía de calidad del software (SQA) es un «patrón de acciones planificado y sistemático» 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 delSoftwarerecomienda un conjunto de actividades de SQA que se enfrentan con la planificación de garantíade 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,
  • auditorias 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.

Cuál es el papel 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óndel 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 SQAidentifica, documenta y siguela pista de las desviaciones desde el proceso y verifica que se han hecho las correcciones.
  • Auditoria 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 productosseleccionados; 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.


1 comentario:

  1. Hey ese mapa mental no lo puedes subir con mejor calidad. gracias de antemano

    ResponderEliminar