Las Factorías de Software según niveles de madurez ISO

Transcripción

1 Las Factorías de Software según niveles de madurez ISO Dr. Javier Garzás JORNADA. El modelo de AENOR de Gobierno y Gestión de las TICs con estándares ISO. Organizada por:

2 Introducción Calidad Software, Procesos e ISO La ISO y los niveles de madurez La auditoría de certificación Algunas experiencias ISO y metodologías ágiles

3 España, primera potencia europea en certificaciones de la calidad software

4 70% De crecimiento en 5 años

5 Un modelo tradicional, de factoría de software, (rrhh a salarios competitivos), podría ser una amenaza INTECO (2009) 5

6 Amenaza: Competir por cantidad- persona - precio, con poca estructura y productividad, etc. INTECO (2009)

7 Méjico. Moprosoft Evalprosoft. TSP/PSP Brasil. MPS.BR Iberoamérica. Competisoft

8 Necesidad: Estrategia, y Equipos de alta productividad

9 La externalización es el área de mayor crecimiento (ASIMELEC)

10 Organización Desarrollo CPD Crece la demanda de SI Crece la complejidad del software Complejo encontrar profesionales KYBELE CONSULTING S.L. - Copyright 2011 All rights reserved. Contains propietary information.

11 INE y

12 Organización Desarrollo CPD Fábrica Software Fábrica Software Desarrollo CPD Desarrollo

13

14

15 Si el cliente no demanda calidad, probablemente no la recibirá Humphrey, W. H. (2005). Acquiring Quality Software

16 Hoy, para competir por la subcontratación de un proyecto, es necesario disponer de certificaciones de la calidad. La práctica totalidad de los pliegos las requieren

17 Organización Desarrollo CPD Fábrica Software Fábrica Software Fábrica Software Desarrollo Desarrollo Desarrollo

18 Tipo de certificación Importe de la ayuda CMMI o SPICE Nivel CMMI o SPICE Nivel CMMI o SPICE Nivel CMMI o SPICE Nivel

19 2011

20 ISO ISO UP / Open UP ISO XP SCRUM

21 ÁGIL Procesos 21

22

23 Dimensiones de la calidad software

24 La calidad del producto depende de la calidad del proceso usado para desarrollarlo Humphrey, W. H. (2005). Acquiring Quality Software

25 Organización inmadura Héroes y apaga fuegos Altibajos en productividad Rotación de recursos Planificaciones poco realistas Mucho mantenimiento

26 Organización madura Conocimiento en la organización Procesos definidos Calidad esperada Cumple plazos Satisface a los clientes

27 2011

28 2011

29 2011

30 2011

31 QUÉ hacer? MODELO DE PROCESOS CMMI DEV ISO CÓMO hacerlo? METODOLOGÍAS Tradicionales Ágiles

32 Desarrollo Explotación CMMI DEV ISO ISO 20000

33 2011

34 2011

35 Percepción de la empresa española: CMMI e ISO/IEC son los modelos referentes INTECO (2008)

36 ISO Norma internacional para establecer y mejorar la capacidad y madurez (evaluación) de los procesos

37 n

38 Optimizando 3 Establecida 4 Predecible Niveles de madurez Mejora continua de los procesos Gestión cuantitativa Procesos adaptados - estándares. 1 Básica 2 Gestionada 0 Inmadura Gestión de procesos y los productos Objetivos de los procesos. No hay implementación de procesos.

39 Esquema normalmente aplicado en software

40 ISO (2 y 7) 5 Optimizando 3 Establecida 0 Inmadura 4 Predecible 2 Gestionada 1 Básica Esquema AENOR ISO Requisitos Arquitectura Planificación Seguimiento Verificación Etc.

41 Atributos de proceso PA 1.1 Realización del proceso CAP Alcanzar los resultados del proceso (outcomes) PA 2.1 Gestión de la realización CAP Definir los objetivos del proceso CAP Planificar y controlar el proceso CAP Adaptar la realización del proceso CAP Asignar las responsabilidades del proceso CAP Asignar los recursos y la información para el proceso CAP Gestionar la comunicación entre las partes involucradas PA 2.2 Gestión de los productos de trabajo CAP Definir los requisitos para los productos de trabajo CAP Definir los requisitos para la documentación y control de los productos CAP Identificar, documentar y controlar los productos de trabajo CAP Revisar y adaptar los productos de trabajo para cumplir los requisitos definidos

42 Atributos de proceso PA 3.1 Definición del proceso estándar CAP Definir un proceso estándar CAP Determinar la secuencia de ejecución y su interacción con otros procesos CAP Identificar los roles y la capacitación del proceso estándar CAP Identificar la infraestructura y el entorno de trabajo del proceso estándar CAP Determinar los métodos para controlar la efectividad del proceso estándar PA 3.2 Despliegue del proceso CAP Adaptar un proceso estándar CAP Asignar y comunicar los roles, responsabilidades para el proceso adaptado CAP Asegurar la capacitación necesaria para realizar el proceso CAP Proporcionar recursos e información para el proceso CAP Proporcionar la infraestructura de proceso adecuada para el proceso adaptado CAP Recoger y analizar los datos sobre la realización del proceso

43

44 5 Optimizando 4 NIVEL 0 Organización inmadura La organización no tiene una implementación de los procesos 3 Establecida 1 Básica 0 Inmadura Predecible 2 Gestionada

45 5 Optimizando NIVEL 1 Organización básica Proceso de Suministro Proceso de Gestión del Modelo de Ciclo de Vida Proceso de Gestión de la Configuración del Software 3 Establecida 1 Básica 0 Inmadura 4 Predecible 2 Gestionada

46 NIVEL 2 Organización gestionada Proceso de Definición de Requisitos de los Stakeholders Proceso de Análisis de los Requisitos del Sistema Proceso de Planificación del Proyecto Proceso de Evaluación y Control del Proyecto Proceso de Gestión de la Configuración Proceso de Medición Proceso de Aseguramiento de la Calidad del Software 5 Optimizando 3 Establecida 1 Básica 0 Inmadura 4 Predecible 2 Gestionada

47 Las claves de un nivel 2 Trazabilidad Ciclo de vida Control de calidad Revisión por la dirección Gestión del Proyecto

48 Proceso de suministro (SUM) RP.1 Los clientes se identifican RP.2 Se da respuesta a la solicitud del cliente RP.3 Se establece un acuerdo entre el cliente y el proveedor, para el desarrollo, mantenimiento, explotación, entrega e implantación RP.4 El proveedor desarrolla un producto o servicio que cumple los requisitos acordados RP.5 El producto y/o servicio se entrega al cliente conforme con los requisitos acordados RP.6 El producto se implanta conforme con los requisitos acordados

49 Proceso de gestión del modelo de ciclo de vida (MCV) RP.1 Se proporcionan políticas y procedimientos para la gestión y el despliegue de modelos y procesos del ciclo de vida RP.2 Está definida la responsabilidad y la autoridad para la gestión del ciclo de vida RP.3 Se definen, mantienen y mejoran los procesos, modelos y procedimientos del ciclo de vida RP.4 Se implementan, de manera priorizada, las mejoras sobre el proceso del ciclo de vida

50 Proceso de gestión de la configuración del software (GCS) RP.1 Se desarrolla una estrategia de gestión de la configuración (Ej. Políticas de etiquetado, estrategias de ramas, nombrado de versiones, etc.) RP.2 Se identifican, definen y colocan en la línea base los productos generados por el proceso o proyecto. (Ej. Requisitos, código, pruebas, etc.) RP.3 Se controlan las modificaciones y versiones de los elementos (Ej. Procedimiento de control de cambios) RP.4 Las modificaciones y versiones están disponibles para las partes afectadas

51 Proceso de gestión de la configuración del software (GCS) RP.5 Se registra e informa del estado de los elementos y sus modificaciones (Ej. Nº de cambios, últimas versiones, comparativa) RP.6 Se asegura la integridad y la consistencia de los elementos (Ej. Auditorías de gestión de la configuración) RP.7 Se controla el almacenamiento, tratamiento y entrega de los productos (Ej. Copias de seguridad, etc.)

52 Proceso de definición de requisitos de stakeholders (RQU) RP.1 Se especifican las características requeridas y el contexto de uso de los servicios RP.2 Se definen las restricciones del sistema RP.3 Existe trazabilidad de los requisitos de stakeholder, a los stakeholders y a sus necesidades RP.4 Se describe una base para la definición de los requisitos del sistema RP.5 Se define una base para validar la conformidad de los servicios RP.6 Se proporciona una base para negociar y acordar la entrega de un producto o servicio

53 Proceso de análisis de los requisitos del sistema (RQSIS) RP.1 Se establece y define un conjunto de requisitos funcionales y no-funcionales del sistema, que describen el problema a resolver RP.2 Se realizan técnicas para optimizar la solución seleccionada para el proyecto RP.3 Los requisitos del sistema se analizan para comprobar su precisión y capacidad de ser probados RP.4 Se comprende el impacto de los requisitos del sistema en el entorno de explotación RP.5 Los requisitos se priorizan, aprueban y actualizan

54 Proceso de análisis de los requisitos del sistema (RQSIS) RP.6 Se establece la consistencia y la trazabilidad entre los requisitos del sistema y la línea base de requisitos del cliente RP.7 Los cambios en la línea base se evalúan frente al coste, calendario e impacto técnico RP.8 Los requisitos del sistema se comunican a todas las partes y se colocan en la línea base

55 Proceso de planificación del proyecto (PP) RP.1 Se define el alcance del trabajo a desarrollar en el proyecto RP.2 Se evalúa la viabilidad de alcanzar los objetivos del proyecto con los recursos disponibles y las restricciones existentes RP.3 Se estima el tamaño y el esfuerzo de las tareas y recursos necesarios para completar el trabajo RP.4 Se identifican las interfaces entre los elementos del proyecto, con otros proyectos y con unidades de la organización RP.5 Se desarrollan planes para la ejecución del proyecto RP.6 Se ponen en marcha los planes para la ejecución del proyecto

56 Proceso de evaluación y control del proyecto (EPC) RP.1 Se controla e informa sobre el progreso del proyecto RP.2 Se controlan las interfaces entre los elementos del proyecto, con otros proyectos y unidades de la organización RP.3 Se toman acciones para corregir las desviaciones respecto a los planes y para prevenir problemas cuando no se cumplen los objetivos del proyecto RP.4 Se alcanzan y registran los objetivos del proyecto (Ej. Productos, actividades y tareas completadas)

57 Proceso de gestión de la configuración (GC) RP.1 Se define una estrategia para la gestión de la configuración (políticas de etiquetado, estrategias de ramas, nombrado de versiones, etc.) RP.2 Se definen los elementos requeridos para la gestión de la configuración RP.3 Se establecen las líneas base de la configuración RP.4 Se controlan los cambios a los elementos que se encuentran bajo la gestión de configuración RP.5 Se controla la configuración de los entregables RP.6 El estado de los elementos que están bajo gestión de la configuración está disponible durante el ciclo de vida

58 Proceso de medición (MED) RP.1 Se identifican las necesidades de información de los procesos RP.2 Se identifican y/o desarrollan un conjunto de medidas a partir de las necesidades de información RP.3 Se identifican y planifican las actividades de medición RP.4 Los datos requeridos se recogen, almacenan, analizan, y los resultados se interpretan RP.5 La información se utiliza para apoyar las decisiones y proporcionar una base objetiva para la comunicación RP.6 Se evalúa el proceso de medición y las medidas RP.7 Las mejoras se comunican al responsable del proceso de medición

59 Proceso de aseguramiento de la calidad del software (ACS) RP.1 Se desarrolla una estrategia para llevar a cabo el aseguramiento de la calidad (Ej. Plan, estándares de codificación, políticas, checklists, etc.) RP.2 Se producen y se mantienen evidencias de aseguramiento de la calidad software (Ej. Actividades y tareas de QA realizadas) RP.3 Se identifican y registran problemas y noconformidades con los requisitos RP.4 Se verifica que los productos, procesos y actividades cumplen con los estándares, procedimientos y requisitos

60 Las claves de un nivel 2 Trazabilidad Ciclo de vida Control de calidad Revisión por la dirección Gestión del Proyecto

61 NIVEL 3 Organización establecida Proceso de Análisis de Requisitos del Software Proceso de Diseño de la Arquitectura del Software 5 Optimizando 3 Establecida 4 Predecible Proceso de Diseño de la Arquitectura del Sistema Proceso de Gestión de Infraestructuras Proceso de Gestión de Recursos Humanos Proceso de Gestión de Riesgos 1 Básica 2 Gestionada 0 Inmadura

62 NIVEL 3 Organización establecida 5 Optimizando 4 Proceso de Gestión de la Decisión Proceso de Integración del Software Proceso de Integración del Sistema Proceso de Verificación del Software Proceso de Validación del Software 3 Establecida 1 Básica 0 Inmadura Predecible 2 Gestionada

63 Las claves de un nivel 3 Proceso estándar Visión de empresa vs proyecto Trazabilidad Diseño / Arquitectura Pruebas, verificar, validar

64

65 CUESTIONARIO PRELIMINAR Y SOLICITUD AUDITORÍAS DE RENOVACIÓN (AL TERCER AÑO) AUDITORÍAS DE SEGUIMIENTO (AL SEGUNDO AÑO) AUDITORÍAS DE SEGUIMIENTO (AL PRIMER AÑO) Auditorías de mantenimiento de la certificación FASE 1: PLANIFICACIÓN DE LA AUDITORÍA Y ESTUDIO DE DOCUMENTACIÓN Auditoría de certificación REGISTRAR LOS RESULTADOS CONCESIÓN DEL CERTIFICADO Informe fase 1 FASE 2 a: REALIZACIÓN DE LA AUDITORÍA Informe final FASE 2 b: ELABORACIÓN DEL INFORME DE EVALUACIÓN Y DECISIÓN Informe de decisión y evaluación

66 LUGAR FASES DE LA AUDITORÍA DURACIÓN 3 DÍAS 4 DÍAS 2 DÍAS Fase 1: Planificación de la auditoría y estudio de documentación Fase 2 a: Realización de la auditoría Fase 2 b: Elaboración y registro del Informe IN SITU AENOR IN SITU AENOR IN SITU AENOR

67 Evidencias directas Evidencias Indirectas Afirmaciones

68 Evidencias sobre la implementación de los procesos (EIP) RESULTADOS DEL PROCESO PROCESO DE SUMINISTRO LOCALIZACIÓN DE LA EVIDENCIA Documentación Evidencia Directa Evidencia Indirecta Afirmación RP.1 Los clientes se identifican RP.2 Se da respuesta a la solicitud del cliente RP.3 Se establece un acuerdo entre el cliente y el proveedor, para el desarrollo, mantenimiento, explotación, entrega e implantación RP.4 El proveedor desarrolla un producto o servicio que cumple los requisitos acordados RP. 5 El producto y/o servicio se entrega al cliente conforme con los requisitos acordados RP.6 El producto se implanta conforme con los requisitos acordados

69 Evidencia Objetiva = Documentación Proceso AND Evidencia Directa AND (Evidencia Indirecta OR Afirmación)

70 Evidencia objetiva Debe haber evidencia objetiva de cada uno de los resultados del proceso (RP) (ISO 12207) y componentes del AP (CAP) para cada uno de los procesos dentro del nivel de madurez EVIDENCIA OBJETIVA = DOCUMENTACIÓN PROCESO AND EVIDENCIA DIRECTA AND (EVIDENCIA INDIRECTA OR ORAFIRMACIÓN)

71 Evidencia objetiva Debe haber evidencia objetiva de cada uno de los resultados del proceso (RP) (ISO 12207) y componentes del AP (CAP) para cada uno de los procesos dentro del nivel de madurez EVIDENCIA OBJETIVA = DOCUMENTACIÓN PROCESO AND EVIDENCIA DIRECTA AND (EVIDENCIA INDIRECTA OR ORAFIRMACIÓN) AP 1.1 Realización del proceso CAP Alcanzar los resultados del proceso (outcomes) AP 2.1 Gestión de la realización CAP Definir los objetivos del proceso CAP Planificar y controlar el proceso CAP Adaptar la realización del proceso CAP Asignar las responsabilidades del proceso CAP Asignar los recursos y la información para el proceso CAP Gestionar la comunicación entre las partes involucradas AP 2.2 Gestión de los productos de trabajo CAP Definir los requisitos para los productos de trabajo CAP Definir los requisitos para la documentación y control de los productos CAP Identificar, documentar y controlar los productos de trabajo CAP Revisar y adaptar los productos de trabajo para cumplir los requisitos definidos

72 Evidencia objetiva Debe haber evidencia objetiva de cada uno de los resultados del proceso (RP) (ISO 12207) y componentes del AP (CAP) para cada uno de los procesos dentro del nivel de madurez EVIDENCIA OBJETIVA = DOCUMENTACIÓN PROCESO AND EVIDENCIA DIRECTA AND (EVIDENCIA INDIRECTA OR ORAFIRMACIÓN) AP 1.1 Realización del proceso CAP Alcanzar los resultados del proceso (outcomes) AP 2.1 Gestión de la realización CAP Definir los objetivos del proceso CAP Planificar y controlar el proceso CAP Adaptar la realización del proceso CAP Asignar las responsabilidades del proceso CAP Asignar los recursos y la información para el proceso CAP Gestionar la comunicación entre las partes involucradas AP 2.2 Gestión de los productos de trabajo CAP Definir los requisitos para los productos de trabajo CAP Definir los requisitos para la documentación y control de los productos CAP Identificar, documentar y controlar los productos de trabajo Nivel 3 de madurez CAP Revisar y adaptar los productos de trabajo para cumplir los requisitos definidos Proceso de de Suministro Proceso de de Definición de de Requisitos de de los los Stakeholders Proceso de de Análisis de de los los Requisitos del del Sistema Proceso de de Gestión del del Modelo Modelo de de Ciclo Ciclo de de Vida Vida Proceso de de Planificación del del Proyecto Nivel 2 de madurez Proceso de de Evaluación y Control Control del del Proyecto Proceso de de Gestión de de la la Configuración del del Software Proceso de de Gestión de de la la Configuración Proceso de de Medición Proceso de de Aseguramiento de de la la Calidad del del Software Nivel 1 de madurez

73 Se debe seleccionar una muestra de al menos 4 proyectos (al menos uno proyecto objetivo )

74 Calificación del atributo de proceso (AP) Completamente alcanzado (F) Ampliamente alcanzado (L) Parcialmente alcanzado (P) No alcanzado (N) Descripción Entre el 86% 100% de los CAP y RP del atributo de proceso son óptimos. Entre el 51% 85% de los CAP y RP del atributo de proceso son óptimos. Entre el 16% 50% de los CAP y RP del atributo de proceso son óptimos. Entre el 0% 15% de los CAP y RP del atributo de proceso son óptimos.

75 Nivel de madurez Nivel 1 Nivel 2 Atributo de proceso (AP) Todos los procesos AP 1.1 Realización del proceso Todos los procesos AP 1.1 Realización del proceso AP 2.1 Gestión de la realización AP 2.2 Gestión de los productos de trabajo Calificación atributo de proceso L ó F F L ó F L ó F

76

77

78 Razones? 1. Ventaja competitiva (62,5%) 2.Cultura organizativa (56,2%) 3.Satisfacción del cliente (50%) 4.Mejora de productividad (37%) 5.Crecimiento (31%)

79 5 áreas más problemáticas 4 Aseguramiento de la Calidad Planificación del Proyecto ,9% 21,1% Gestión de la Configuración 12,9% 1 Medición 30,5% 2 Institucionaliza ción 23,5%

80 En gestión de proyectos, la ausencia de método de estimación es el problema que más se repite

81 Otras certificaciones ISO 27001; 12,50% ISO 14001; 18,75% Otras; 12,50% Ninguna; 25,00% ISO 9001; 31,25%

82

83 Put Your Process on a Diet (Martin Fowler)

84 ÁGIL Procesos 84

85 Predicción vs Evolución

86 Cascada (Predicción)

87 Ciclo de vida en Cascada

88 Espiral (Evolución)

89 Iterativo e incremental

90

91 Adaptación al cambio Menos documentación Contratos flexibles Interacción con el cliente

92

93 Scrum

94 KANBAN Kanban

95

96 QUÉ? CÓMO? SCRUM

98 KYBELE CONSULTING S.L. - Copyright 2011 All rights reserved. Contains propietary information. PLANIFICACIÓN DEL PROYECTO (PP) Y SCRUM Satisfecho OUTCOME 1 PRÁCTICAS SCRUM Se define el alcance del trabajo Pila del Producto y conjunto de iteraciones Satisfecho OUTCOME 2 PRÁCTICAS SCRUM Se evalúa la viabilidad del proyecto Reunión Planificación y Seguimiento de Iteración, funcionalidades e impedimentos. Satisfecho OUTCOME 3 PRÁCTICAS SCRUM Se estima el tamaño y el esfuerzo Estimación del Product Backlog y del Sprint Backlog (estimación de Póker o de Fibonacci)

99 KYBELE CONSULTING S.L. - Copyright 2011 All rights reserved. Contains propietary information. EVALUACIÓN Y CONTROL DEL PROYECTO (ECP) Y SCRUM OUTCOME 3 PRÁCTICAS SCRUM Satisfecho Acciones para corregir desviaciones respecto a planes Burndown Reunión diaria Impedimentos Resolución de impedimentos Satisfecho OUTCOME 4 PRÁCTICAS SCRUM Se alcanzan y se registran los objetivos del proyecto. Pila de la Iteración y Pila del Producto

102 Y QUE OCURRE CON LA DOCUMENTACIÓN? 102

103 Documentar, de manera ágil, pero documentar [ ] Frecuentemente escucho a los desarrolladores decir que no les gusta documentar, que no lo encuentran útil, pero No era el objetivo principal de documentar el ayudar a otros? Cómo es posible una visión tan distorsionada de la documentación? Agile Documentation, Anyone? por Bran Selic IEEE Software de noviembre

105 Cuántas organizaciones implantan CMMI/ISO con métodos ágiles? Tradicional NO 43,75% 56,25% SI Prácticas Ágiles (estadística en base a más de 30 proyectos CMMI / ISO desarrollados por Kybele Consulting)

106 KYBELE CONSULTING S.L. - Copyright 2011 All rights reserved. Contains propietary information. SCRUM proporciona apoyo (ojo, no garantía de certificación) para la implantación de los procesos del nivel 2 de madurez

107

108

111

112 CMMI o ISO 15504? 1.CMMI más conocido internacionalmente 2.ISO más compatible con otras ISO 3.El SEI no certifica vs p.e. AENOR

113 Nivel 3 ISO/IEC PYME Nivel 2 ISO/IEC PYME Valor discreto S L P W Grado de relación Fuerte Amplia Parcial Débil No relacionado Porcentaje asociado 86% a 100% 51% a 85% 16% a 50% 1% a 15% 0% CONFIGURATION MANAGEMENT PROCESS AND PRODUCT QUALITY ASSURANCE REQUIREMENTS MANAGEMENT MEASUREMENT AND ANALYSIS PROJECT MONITORING AND CONTROL PROJECT PLANNING RISK MANAGEMENT ORGANIZATIONAL TRAINING VALIDATION TECHNICAL SOLUTION REQUIREMENTS DEVELOPMENT DECISION ANALYSIS AND RESOLUTION VERIFICATION ORGANIZATIONAL PROCESS FOCUS PRODUCT INTEGRATION Grado de Relación S S S S L L S S L L L P P P P P P Infrastructure Management Process W Human Resource Management Process W S P W Decision Management Process P Risk Management Process W W S System Architectural Design Process P P System Integration Process P Software Requirements Analysis Process L P Software Architectural Design Process P P Software Integration Process P Software Verification Process P Software Validation Process Supply Process L W Life Cycle Model Management Process P W P Project Planning Process P L W Project Assessment and Control Process L W W Configuration Management Process S Measurement Process S W Stakeholder Requirements Definition Process P P System Requirements Analysis Process L P Software Configuration Management Process S Software Quality Assurance Process S ORGANIZATIONAL PROCESS DEFINITION +IPPD INTEGRATED PROJECT MANAGEMENT +IPPD

114 Se reconoce el valor de ISO y es deseable que la nueva versión de CMMI sea lo más compatible posible Mike Phillips (2010) SEI

115 &

116 Certificación sin ingeniería del software no es útil ( o solo sirve para los pliegos)

117 What are the most exciting/promising software engineering ideas or techniques on the horizon? I don t think that the most promising ideas are on the horizon. They are already here and have been here for years but are not being used properly. Parnas

119 Javier Garzás ybele onsulting JORNADA. El modelo de AENOR de Gobierno y Gestión de las TICs con estándares ISO. Organizada por: