DIPLOMADO DE INGENIERÍA DE SOFTWARE

1. DIPLOMADO DE INGENIERÍA DE SOFTWARE Módulo 5 Aseguramiento de Calidad de Software

2. Tema 8. Estándares de calidad del proceso y del producto. Establecerán el proceso de aseguramiento de calidad

3. 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.

4. 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.

5. Comparativo :: Clases de estándares en sqa

6. Ejemplos de estándares en uso Administración de la calidad de software Ciclo de vida del desarrollo de software • ISO 9000-3 • IEEE Std 730-1998 • Planes paraaseguramiento de caldiad de software • IEEE/IEA 12207 • IEEE Std 1012-1998 • Verificaciónyvalidación de software • IEEE Std 1045-1992 • Métricas de productividad de software

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

8. 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.

9. Anexos en aseguramiento de calidad en software Organización Internacional para la Estandarización (ISO) Capability Maturity Model Integration (CMMI)

10. 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.

11. Organización Internacional para la Estandarización (ISO) • Clausulas principales • Sistema de administración de calidad • Responsabilidad de administración • Administración de recursos • Realización del producto • 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.)

12. 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.

13. 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.

14. 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.

15. Tema 9. Procesos y entidades certificadoras de calidad de software. Conocerán los procesos más importantes de certificación de software

16. 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

17. Evolución de modelos CMM "la calidad del resultado depende principalmente de la calidad de los procesos empleados en su desarrollo”. Jurán • 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).

18. 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)

19. 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.

20. 22 áreas de proceso :: CMMI v1.2 (CMMI-DEV) El modelo CMMI v1.2(CMMI-DEV) contiene las siguientes 22 áreas de proceso: • 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)

21. El modelo CMMI v1.2 (CMMI-DEV)

23. 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.

27. CMMI® for Services, Version 1.2CMMI-SVC, V1.2 CMMI Model Components

28. CMMI® for Services, Version 1.2CMMI-SVC, V1.2 Comparison of Capability and Maturity Levels

29. Marcos de referenciapara TI • CMMI – SCAMPI • MoProSoft – EvalProSoft • eSCM-CL / eSCM-SP • ITIL • PSP TSP • COBIT • SPICE • Etc.

30. El caso del java community process • Mecanismoregulador de la plataforma java • Integradoporindustriaseindividuos • Alta vinculación con el ambitoempresarial • Basado en especificaciones • JSR. Java Specification Request Ejemploinstitucional de un marcoad hoc para el aseguramiento de la calidad de cadaespecificación.

31. Discusiones finales