DIPLOMADO DE INGENIERÍA DE SOFTWAREMódulo 5 Aseguramiento de Calidad de Software

TEMA 8. ESTÁNDARES DE CALIDAD DEL PROCESO Y DEL PRODUCTO.Establecerán el proceso de aseguramiento de calidad

BENEFICIOS DE USAR ESTÁNDARES EN EL ASEGURAMIENTO DE CALIDAD DE SOFTWARE Habilidades para utilizar las metodologías y

procedimientos profesionales más sofisticados y comprensibles.

Mejor entendimiento, colaboración y cooperación entre usuarios de los mismos estándares: Entre miembros del equipo y entre equipos del

proyecto. Entre desarrolladores del software y

participantes extenos en el proyecto. Entre proveedores y clientes.

CONTRIBUCIONES REALIZADAS POR EL USO DE ESTÁNDARES Brindar metodologías profesionales para su

uso en el proceso de desarrollo y su administración.

Certificación en servicios de aseguramiento de calidad basados en auditorias de calidad por parte de profesionales independientes.

Herramientas para reconocer las capacidades propias de logros en la planeación y organización de un sistema de aseguramiento de calidad.

COMPARATIVO :: CLASES DE ESTÁNDARES EN SQACaracterísticas

Estándares de administración de calidad

Estándares para los procesos del proyecto

La unidad meta Administración del desarrollo y mantenimiento del software y las unidades específicas de SQA.

Equipo de proyecto para desarrollo y mantenimiento de software.

Enfoque principal

Organización de los sistemas de SQA, infraestructura y requerimientos.

Metodolgías para realizar proyectos de desarrollo y mantenimiento de software.

Objetivos del estándar

Qué a lograr. Cómo a desempeñar.

Metas del estándar

Asegurar la calidad del software de proveedores e inventariar las capacidades de sus procesos de software.

Asegurar la calidad de un proeycto de software específico.

Ejemplos ISO 9000-3; CMMI; ISO/IEC 12207; IEEE Std 1012-1998

EJEMPLOS DE ESTÁNDARES EN USO

ISO 9000-3 IEEE Std 730-1998

Planes para aseguramiento de caldiad de software

IEEE/IEA 12207 IEEE Std 1012-1998

Verificación y validación de software

IEEE Std 1045-1992 Métricas de

productividad de software

Administración de la calidad de software

Ciclo de vida del desarrollo de software

TENDENCIAS EN EL DESARROLLO DE ESTÁNDARES Joint ventures

IEEE/ANSI ISO/IEC IEEE/ISO

Adopción de estándares internacionales , como estándares nacionales, por institutos nacionales de estándares

Aplicación de estándares en la industria de software con cobertura mundial: ISO/IEC 9000-3 :: Estándares de certificación de calidad

para organizaciones de desarrollo y mantenimiento de software.

ISO/IEC 15504 :: Inventario de capacidades en procesos de software

ISO/IEC/IEEE 12207 :: Prácticas en el desarrollo de software

ESTÁNDAR DE CALIDAD ISO 9001 Está expresado en términos generales, y puede ser

interpretado por los desarrolladores de diversos productos.

Para la industria del software los estándares relevantes son: ISO 9001. Quality Systems – Model for Quality

Assurance in Design, Development, Production, Installation and Servicing.

Describe el sistema de calidad utilizado para mantener el desarrollo de un producto que implique diseño.

ISO 9003. Guidelines for Application of ISO 9001 to the Developments, Supply and Maintainance of Software.

Documento específico para el desarrollador de software. ISO 9004. Quality Management and Quality System

Elements – Part 2 -. Directrices para los servicios en software, como soporte de

usuarios.

ANEXOS EN ASEGURAMIENTO DE CALIDAD EN SOFTWARE

Organización Internacional para la Estandarización (ISO)

Capability Maturity Model Integration (CMMI)

ORGANIZACIÓN INTERNACIONAL PARA LA ESTANDARIZACIÓN (ISO) Estructura de la serie ISO 9000 La serie ISO 9000 incluye dos tipos de

normas: Normas contractuales (certificables) Normas guía

Hasta el año 2000 existían tres normas contractuales de aseguramiento de calidad que se distinguían por su cobertura. ISO 9001: 1994 Modelo para el diseño/desarrollo,

producción, instalación y servicio post-venta. ISO 9002: 1994 Modelo para la producción, la instalación y

servicio post – venta. ISO 9003: 1994 Modelo para la inspección y pruebas

finales.

ORGANIZACIÓN INTERNACIONAL PARA LA ESTANDARIZACIÓN (ISO) Clausulas principales

1. Sistema de administración de calidad2. Responsabilidad de administración3. Administración de recursos4. Realización del producto5. Métricas, análisis y mejoras

• Sistema de calidad distintos niveles de abstracción:

QUÉ :: Políticas & Procesos (ISO & PMBOK)

CÓMO :: Procedimientos & Productos de trabajo Plan de calidad (áreas de admon de proys.)

SPICE – SOFTWARE PROCESS IMPROVEMENT AND CAPABILITY DETERMINATION

ISO 15504 (Determinación de la Capacidad y Mejora del Proceso del

Software) SPICE (ISO/IEC 15504) Estándar internacional para la evaluación de

procesos de software. Aplicable en un amplio espectro de:

Dominios. Sectores de negocio. Tipos de organización.

Independientemente de: Estructuras organizativas y filosofías de gestión. Modelos de ciclo de vida, tecnologías o metodologías de

desarrollo.

EVALUACIÓN DE PROCESOS(ASSESSMENT)

La evaluación disciplinada de los procesos que se utilizan en una organización, contra un conjunto de criterios para poder determinar la capacidad de realización de los procesos, sin perder de vista las metas de calidad, costo y tiempo.

El objetivo es distinguir las práctica actual identificando las fuerzas y debilidades, y la capacidad del proceso para controlar o evitar las causas específicas en el pobre desempeño de la calidad, costo o tiempo.

LA NECESIDAD DE UN PROCESO DE EVALUACIÓN Requisitos para llevar a cabo una evaluación:

Planificación detallada, basada en la experiencia. Preparación de equipos y organizaciones. Recogida y registro de la información. Entrevistas, presentaciones y validación de

datos. Un buen proceso de evaluación asegurará:

Repetición del proceso. Comparación de resultados.

TEMA 9. PROCESOS Y ENTIDADES CERTIFICADORAS DE CALIDAD DE SOFTWARE.Conocerán los procesos más importantes de certificación de software

CAPABILITY MATURITY MODEL INTEGRATION (CMMI) Capability Maturity Model Integration (CMMI) es un modelo

para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software.

The Three Critical Dimensions

EVOLUCIÓN DE MODELOS CMM

Entre los principales patrocinadores se incluyen: La Oficina del Secretario de

Defensa (OSD) y La National Defense Industrial

Association. Tras la publicación del modelo CMM

for Software, se comenzaron a desarrollar modelos para mejorar la madurez de las capacidades en otras áreas y ámbitos:

P-CMM: People CMM. SA-CMM: Software Acquisition CMM. SSE-CMM: Security Systems

Engineering CMM. T-CMM: Trusted CMM SE-CMM: Systems Engineering CMM. IPD-CMM: Integrated Product

Development CMM.

CMM Fue desarrollado desde 1987 hasta 1997.

En 2002, se lanzo CMMI Version 1.1. En agosto de 2006 siguió la versión 1.2

El objetivo del proyecto CMMI es mejorar la usabilidad de modelos de madurez integrando varios modelos diferentes en un solo marco (framework). Fue creado por miembros de la industria, el gobierno y el Software Engineering Institute (SEI).

"la calidad del resultado depende principalmente de la calidad de los procesos empleados en su desarrollo”. Jurán

CONSTELACIONES CMMI CMMI ahora incluye el concepto de “constelaciones” CMMI.

Conjunto de componentes CMMI diseñados para atender las necesidades de un área de interés específica.

Una constelación puede producir uno o más modelos CMMI, evaluaciones y materiales de entrenamiento relacionados.

CMMI para Desarrollo fue la primera constelación. La versión actual de CMMI es la versión 1.2. Hay tres

constelaciones de la versión 1.2 disponible: CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2

fue liberado en agosto de 2006. En él se tratan procesos de desarrollo de productos y servicios.

CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2 fue liberado en noviembre de 2007. En él se tratan la gestión de la cadena de suministro, adquisición y contratación externa en los procesos del gobierno y la industria.

CMMI para servicios (CMMI-SVC o CMMI for Services), está diseñado para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios.

Dentro de la constelación CMMI-DEV, existen dos modelos: CMMI-DEV CMMI-DEV + IPPD (Integrated Product and Process Development)

EVALUACIÓN DE CMMI Independientemente de la constelación/modelo que

opta una organización, las prácticas CMMI deben adaptarse a cada organización en función de sus objetivos de negocio.

Las organizaciones no pueden ser certificadas CMMI. Una organización es evaluada.

Recibe una calificación de nivel del 1 al 5 si sigue los niveles de Madurez.

En caso de que la organización quiera, puede elegir áreas de proceso para ser evaluada por los niveles de capacidad en cada una de las Áreas de Proceso, obteniendo el "Perfil de Capacidad" de la Organización.

22 ÁREAS DE PROCESO :: CMMI V1.2 (CMMI-DEV)

Análisis de Causas y Resolución (CAR) Gestión de la configuración (CM) Análisis de Decisiones y Resolución

(DAR) Gestión Integrada de Proyectos (IPM) Medición y Análisis (MA) Innovación y Despliegue

Organizacionales(OID) Definición de procesos

organizacionales (OPD) Enfoque Organizacional en Procesos

(OPF) Rendimiento de Procesos

Organizacionales (OPP) Formación Organizacional (OT) Monitorización y Control de Proyecto

(PMC)

Planificación de proyecto (PP) Aseguramiento de calidad de

Procesos y Productos (PPQA) Integración de Producto (PI) Gestión Cuantitativa de Proyectos

(QPM) Gestión de Requerimientos (REQM) Desarrollo de Requerimientos (RD) Gestión de Riesgos (RSKM) Gestión de Acuerdos con

Proveedores (SAM) Solución Técnica (TS) Validación (VAL) Verificación (VER)

El modelo CMMI v1.2(CMMI-DEV) contiene las siguientes 22 áreas de proceso:

EL MODELO CMMI V1.2 (CMMI-DEV)

Componentes Área de proceso: Conjunto de practicas relacionadas que son ejecutadas de forma conjunta para

conseguir un conjunto de objetivos Componentes Requeridos

Objetivo genérico: Los objetivos genéricos asociados a un nivel de capacidad establecen lo que una organización debe alcanzar en ese nivel de capacidad. El logro de cada uno de esos objetivos en un área de proceso significa mejorar el control en la ejecución del área de proceso

Objetivo específico: Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades que describen que se debe implementar para satisfacer el propósito del área de proceso.

Componentes Esperados Práctica genérica: Una practica genérica se aplica a cualquier área de proceso porque puede mejorar el

funcionamiento y el control de cualquier proceso. Práctica específica: Una practica específica es una actividad que se considera importante en la realización del

objetivo especifico al cual está asociado.Las prácticas específicas describen las actividades esperadas para lograr la meta específica de un área de proceso

Componentes Informativos Propósito Notas introductorias Referencias Nombres Tablas de relaciones práctica – objetivo Prácticas Productos típicos Sub-prácticas: Una sub-practica es una descripción detallada que sirve como guía para la interpretación de una

practica genérica o especifica. Ampliaciones de disciplina: Las ampliaciones contienen información relevante de una disciplina particular y

relacionada con una practica especifica Elaboraciones de prácticas genéricas: Una elaboración de una practica genérica es una guía de cómo la practica

genérica debe aplicarse al área de proceso Evaluación SCAMPI

Si se emplea el modelo para medir el nivel de los procesos de una organización, éste define la manera en la que se debe hacer la evaluación.: SCAMPI Standard CMMI Appraisal Method for Process Improvement.

Evolución futura SEI ha anunciado que a partir de la versión 1.2 se refundirán en un único documento las versiones continua y

escalonada, y que el modelo de evaluación SCAMPI también cambiará. El actual será válido hasta 2009. El próximo incorpora caducidad como si no se tratara de evaluación sino de certificación.

CMMI® FOR SERVICES, VERSION 1.2CMMI-SVC, V1.2

CMMI Model Components

CMMI® FOR SERVICES, VERSION 1.2CMMI-SVC, V1.2

Comparison of Capability and Maturity Levels

MARCOS DE REFERENCIA PARA TI CMMI – SCAMPI MoProSoft –

EvalProSoft eSCM-CL / eSCM-SP ITIL PSP TSP COBIT SPICE Etc.

EL CASO DEL JAVA COMMUNITY PROCESS Mecanismo regulador de la plataforma java Integrado por industrias e individuos Alta vinculación con el ambito empresarial Basado en especificaciones

JSR. Java Specification Request

Ejemplo institucional de un marco ad hoc para el aseguramiento de la calidad de cada especificación.

DISCUSIONES FINALES