Repositorio Institucional de Documentos

P r o y e c t o F i n d e C a r r e r a - I n g e n i e r í a I n f o r m á t i c a Francisco Javier Soler Martínez Director: D. Javier Campos Laclaustra Departamento de Informática e Ingeniería de Sistemas Centro Politécnico Superior - Universidad de Zaragoza Agosto 2010 C CE EN NT TR RO O P PO OL LI IT TÉ ÉC CN NI IC CO O S SU UP PE ER RI IO OR R U UN NI IV VE ER RS SI ID DA AD D D DE E Z ZA AR RA AG GO OZ ZA A Análisis de la implantación del Modelo de Integración de Madurez de Capacidades “CMMi” en organizaciones dedicadas a desarrollo de proyectos de software 2 Agradecimientos: A Montse y Panchito por el apoyo para terminar una tarea que se había demorado demasiado. Su apoyo ha sido definitivo. A mi hermano que desde el cielo guía mis acciones. A mis padres por haber hecho que llegase hasta donde he llegado a pesar de todas las dificultades que nos ha tocado vivir. A mis compañeros de la carrera, por todos los momentos que pasamos juntos. A pesar del tiempo, siempre estarán en mi mente. Por último, agradecer a Javier Campos el haber apoyado este proyecto con su tiempo y dedicación desinteresada. 3 Índice 1 Introducción .......................................................................................................................... 4 1.1 Contexto ........................................................................................................................ 4 1.2 Descripción del proyecto .............................................................................................. 4 1.3 Estructura de la propuesta ............................................................................................ 5 2 Descripción de los modelos .................................................................................................. 6 2.1 CMMi Dev ..................................................................................................................... 8 2.2 eSCM-SP ........................................................................................................................ 9 2.3 ISO 9001 ...................................................................................................................... 10 2.4 ITIL ............................................................................................................................... 11 2.5 Six Sigma ..................................................................................................................... 12 2.6 ISO 27001 .................................................................................................................... 12 3 Proceso de certificación: fases y puntos a considerar ........................................................ 14 3.1 Análisis técnico-económico para validar el modelo y la certificación adecuada. ....... 14 3.1.1 Conclusiones ....................................................................................................... 19 3.2 Proceso de certificación (SCAMPI) .............................................................................. 20 3.2.1 Conclusiones ....................................................................................................... 23 3.3 Proceso de mejora continua o mantenimiento .......................................................... 24 3.3.1 Conclusiones ....................................................................................................... 26 4 Conclusiones del análisis ..................................................................................................... 27 5 Glosario de referencias ....................................................................................................... 29 6 Certificado de depósito en Zaguan ..................................................................................... 30 4 1 Introducción 1.1 Contexto Este proyecto es el resultado de la experiencia, durante los últimos 12 años, en la realización de proyectos de desarrollo de software y particularmente en la gestión de los mismos. Dicha gestión ha incluido no solo la supervisión y dirección de los mismos, sino el seguimiento y compromiso por mejorar la entrega mediante el aumento de la calidad en todas y cada una de las fases. Todo este conocimiento y la experiencia se ha plasmado en este proyecto centrado en el análisis de la implementación del modelo de calidad CMMi1 en organizaciones dedicadas a proyectos de software. 1.2 Descripción del proyecto Los últimos años se ha producido una carrera, de todas las organizaciones que desarrollan software, por la reducción de costes. Esto se ha producido por diversos factores: 1. Apertura de factorías de software en Asia, lo cual hizo posible mantener, o incluso descender, el precio por jornada al cliente durante varios años manteniendo los márgenes operativos. 2. Entrada de nuevos actores en los mercados maduros, EEUU o Europa, que han provocado la escalada de reducción de precio. 3. Crisis económica que ha reducido la inversión en nuevos desarrollos, lo cual ha lastrado los resultados de todas las organizaciones. Este fenómeno se ha mantenido durante unos años, pero ha provocado un descenso en la calidad de los entregables debido principalmente a la dificultad en gestionar proyectos con varias localizaciones. Este hecho, unido a otros aspectos, produjo una inquietud por mejorar la calidad en cualquier proyecto relacionado con software: desarrollo, mantenimiento, outsourcing2, servicios, etc. Por ello la gran mayoría de las organizaciones, independientemente del tamaño, añadieron en sus planes estratégicos la adopción de modelos de calidad a sus proyectos. Este hecho que ha sido un factor diferenciador, incluso favoreciendo la resolución de algunas propuestas presentadas (especialmente en el área de gobierno en diferentes países), se ha realizado de diferentes formas, con diferente visión, diferente apoyo de la alta dirección. Este hecho ha provocado que la implementación de dichos modelos de calidad se haya realizado sin la rigurosidad necesaria, provocando que no se hayan alcanzado los resultados previstos, se hayan abandonado los modelos tras un breve tiempo o incluso se hayan relajado algunos aspectos clave en el desarrollo de proyectos software. 1 CMMi: Integración de Modelos de Madurez de Capacidades o Capability Maturity Model Integration http://es.wikipedia.org/wiki/Capability_Maturity_Model_Integration 2 Outsourcing: subcontratación http://es.wikipedia.org/wiki/Subcontratación 5 Este hecho ha creado un interés en realizar un trabajo de análisis, recopilación de información, identificación de problemas y soluciones que se refleja en este proyecto. 1.3 Estructura de la propuesta El proyecto se ha estructurado en 3 partes claramente definidas: 1. Describir los modelos de calidad más populares3 con el objetivo de mostrar las diferencias entre cada uno de ellos. Estas diferencias aclaran la razón por la que la industria del software no dispone de estándares claros genéricos. 2. Describir el proceso de implementación del modelo CMMi. Se ha tomado este modelo por ser el más usado en la industria del software en la actualidad y según los grandes analistas lo va a ser en los próximos años. 3. Mostrar las conclusiones de todo este análisis. 3 Entendiendo por popular aquellos que han tenido una difusión mayor y por consiguiente un numero de implementaciones, o certificaciones, más elevado. 6 2 Descripción de los modelos Debido al gran número de modelos de calidad, estandarización y certificaciones que son aplicables a organizaciones dedicadas al desarrollo del software, la elección del modelo, o modelos, a implantar en una factoría de software debe realizarse tras un análisis detallado. Este análisis debe de contemplar varios factores: Aspectos propios del modelo Aspectos externos al modelo  Áreas fuertes de cada modelo: cada modelo pone su punto de atención en algún aspecto determinado: o Gestión de la calidad: rigor en la gestión de la calidad, en la documentación, en la gestión de configuración, etc. o Tipología del trabajo: desarrollo de nuevas aplicaciones de software, trabajo de mantenimiento de aplicativos, “outsourcing”, servicio de etc. o Áreas de negocio: sistemas de atención al cliente, etc.  Objetivo de negocio cubierto por el modelo: cada modelo tiene sus peculiaridades dependiendo del tipo de trabajo (implementación de sistemas u outsourcing por ejemplo).  Modelos utilizados por la competencia: el estar certificado en un modelo puede producir que se gane o no un proyecto. De ahí que es importante no dar ventajas a los competidores  Modelos requeridos por los clientes: este punto es importante ya que la administración pública requiere unos niveles de calidad que difieren en gran medida de lo que requiere la empresa privada (al menos a nivel de propuesta) El análisis de todos los aspectos facilitará el modelo de calidad, o modelos, que se necesita implantar. A continuación se facilita un gráfico en donde se realiza una comparativa de los sistemas de calidad más usados según las características en las que se enfoca cada uno tomando como base las áreas básicas: 1. Sistema de gestión de calidad 2. Desarrollos de sistemas 3. Outsourcing 7 Existe un solape de objetivos entre los diferentes sistemas de calidad:  Gestión de la calidad mediante planes de revisión continúa a lo largo del proyecto.  Procesos  Exigen un gran proceso de documentación que se debe de realizar El tipo de industria se ha decantado por ciertos modelos:  CMMi es líder en desarrollo y mantenimiento de sistemas  ITIL4 se focaliza en gestión del servicio de IT.  COPC5 se focaliza en sistemas de atención al cliente. Si analizamos los modelos podemos ver la orientación o focalización por tipo de industria de cada uno de ellos según la orientación que hayan sufrido durante su ciclo de vida:  En la gran mayoría de los casos los modelos se han creado basándose en ciertas áreas: o Gestión de proyecto o Gestión de la configuración o Gestión de calidad total o Principios de planificar-hacer-chequear-actuar.  Se focalizan en documentación de los procesos y la actualización de los mismos a lo largo de la vida del proyecto: Por ejemplo: ISO90016 se centra en la rigurosidad de la gestión de procesos como también CMMi y eSCM-SP. De manera similar las técnicas definidas en el modelo Six Sigma nos ayudarían a cumplir los requerimientos de otros modelos como CMMi y eSCM-SP (particularmente en los niveles 4 y 5 de dichos modelos). Otros ejemplos de focalización serían:  CMMi se focaliza principalmente en implementación de sistemas y su mantenimiento.  eSCM-SP se focaliza en desarrollo de IT  COPC se centra en sistemas de atención al cliente  ITIL se ha desarrollado principalmente en la gestión de servicio de IT. Por todo el solape existente entre los más importantes modelos de calidad existentes y la focalización de los mismos según la industria, el tipo de trabajo o área y el objetivo a 4 ITIL: Infraestructura de Tecnologías de Información http://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library 5 COPC: Customer Operations Performance Center Incorporated http://en.wikipedia.org/wiki/COPC_Inc. 6 ISO: Organización internacional para la estandarización http://www.iso.org/iso/home.htm 8 conseguir, conviene profundizar en detalle en cada uno de ellos. A continuación se describen los modelos más utilizados en el mercado de la misma forma para facilitar la comparación entre ellos. 2.1 CMMi Dev CMMi Dev Creador Carnegie Mellon University (Software Engineering Institute) http://www.sei.cmu.edu/cmmi/ El SEI7 facilita servicios relacionados con CMMi: formación, certificaciones, soporte, etc. Este modelo se basa en 5 niveles de certificación según los procesos, definidos por CMMI, para cada nivel que se cumpla8 Level Characteristics Process Areas 5 Optimizing • Improvement is based on common causes of variation • Organizational innovation occurs • • Causal Analysis and Resolution (CAR) • Organization Innovation & Deployment (OID) 4 Quantitatively Managed • Quality and performance are understood and managed in statistical terms • • Organizational Process Performance (OPP) • Quantitative Project Management (QPM) 3 Defined • Project-specific processes are based on a tailored version of an organizationwide process asset • Process improvement is coordinated and managed • There is consistency of performance across all projects in the organization • Decision Analysis and Resolution (DAR) • Integrated Project Management (IPM) • Integrated Supplier Management (ISM) • Integrated Teaming (IT) • Organization Environment for Integration (OEI) • Organizational Process Definition (OPD) • Organizational Process Focus (OPF) • Organizational Training (OT) • Product Integration (PI) • Requirements Development (RD) • Risk Management (RSKM) • Technical Solution (TS) • Validation (VAL) • Verification (VER) 2 Managed • Processes are planned, documented, performed, monitored, and controlled (at the project level) • Objectives are achieved predictably • Similar results are achieved between projects • Configuration Management (CM) • Measurement and Analysis (MA) • Project Monitoring and Control (PMC) • Project Planning (PP) • Process and Product Quality Assurance (PPQA) • Requirements Management (REQM) • Supplier Agreement Management (SAM) 1 Initial • Ad-hoc processes • Reliance on individual heroes • Schedule drives everything • n/a Modelo CMMi-Dev es el resultado de la unión de varios modelos definidos con anterioridad: “CMM for software”, “Systems Engineering CMM”, “Software Acquisition CMM” e “IPPD CMM”. Consiste en una seria de procesos a utilizar en el desarrollo y mantenimiento de proyectos informáticos para aumentar la calidad del software Certificación El proceso de certificación se realiza en áreas concretas dentro de una organización multidisciplinar. Este hecho es importante debido a que una organización puede disponer de certificaciones diversas según su estructura, 7 SEI: Software Engineering Institute http://www.sei.cmu.edu/ 8 La tabla se ha mantenido en inglés para facilitar la transcripción de las siglas utilizadas por CMMi en cada uno de los procesos definidos en cada nivel 9 negocio, industria, etc. La certificación se consigue mediante la realización de 2 procesos de evaluación: 1. “SCAMPI9Class B” – proceso de evaluación preliminar para ver la situación actual con el objetivo de establecer las medidas correctivas para mejorar las áreas en donde no se alcance 2. “SCAMPI Class A” – proceso formal de evaluación. Si se consiguen los objetivos establecidos por el SEI se provee el certificado acorde al nivel obtenido. Beneficios ROI10 4.7:1 aunque el beneficio se mueve en un rango de 2:1 Y 27.7:111 Mejora de Resultados según el promotor de CMMI: http://www.sei.cmu.edu/cmmi/results.html en donde podemos ver resultados facilitados por el promotor de los años 2005 y 2007 para proyectos concretos y datos agregados de varias organizaciones. La mejora media facilitada es: coste (20%), planificación (37%), productividad (62%), calidad (50%) y satisfacción del cliente (14%)12 Situación actual en la industria Las grandes consultoras y empresas desarrolladoras de software poseen áreas certificadas en el nivel 5. El ejército norteamericano fue la organización impulsora de este modelo al ser un requisito necesario para poder presentar propuestas de desarrollo y mantenimiento. Certificación La certificación en sí misma no es relevante aunque el SEI facilita una evaluación estándar llamada SCAMPI (Standard CMMi Appraisal Method for Process Improvement). Se realizan 2 SCAMPIs uno inicial para identificar los puntos que no se cumplen para alcanzar el nivel de certificación deseada y se utiliza para establecer un plan de acción para subsanar dichas deficiencias antes de realizar el SCAMPI final que servirá para certificar el nivel CMMi correspondiente 2.2 eSCM-SP eSCM-SP Creador Carnegie Mellon University (ITSqc13: Centro de cualificación de servicios IT) es la propietaria de eSCM-SP. Está disponible en http://itscq.cs.cmu.edu/downloads El ITSqc facilita servicios relacionados con CMMi: formación, certificaciones, soporte, etc. Modelo eSCM-SP contiene un conjunto de buenas prácticas relacionadas con el “eSourcing14”. 9 Standard CMMI Appraisal Method for Process Improvement 10 ROI: retorno de la inversión http://es.wikipedia.org/wiki/Retorno_de_la_inversión 11 Datos de CMMi 12 Datos de CMMi 13 ITSqc: http://www.itsqc.org/ 16 Definición de métricas Descripción Uno de los aspectos más importantes es la definición de métricas tangibles que ayuden a comparar la situación anterior y posterior a la certificación. Estas métricas deben ayudar a la organización: alta dirección y equipo ejecutivo, a ver la evolución de las mismas a medida que la certificación se madura. Para realizar las comparaciones pertinentes es indispensable realizar un análisis de los valores actuales y pasados para identificar posibles correcciones que se deban realizar en dichos valores de cara a realizar unas comparaciones efectivas. Puntos a analizar Consideraciones comunes Coste Aunque no las más importantes a priori, son unas métricas que pueden determinar la planificación y la decisión con la que se aborda las decisiones finales tras la fase de análisis. La realización del caso de negocio es importante de cara a obtener las métricas correspondientes Los tipos de medidas que se deben de considerar son: 1. Coste del análisis: incluye el coste de todo el equipo que realiza el análisis, las reuniones con alta dirección y resto de equipo ejecutivo. 2. Coste de la implantación: incluye no solo el coste del equipo de mejora continua y el coste de los certificadores. 3. Coste del mantenimiento y mejora continua de todos los procesos 4. Coste de herramientas, procesos y documentación que se debe generar para ayudar a los proyectos a seguir los procesos. 5. Coste de las personas asignadas a los distintos proyectos partícipes en la certificación por las tareas a realizar: actualización de documentación, reuniones, SCAMPI-B, SCAMPI-A, formación, etc.  Es habitual que no todos los costes se incluyan en el modelo de negocio ya que se suelen despreciar o simplemente contabilizar en los costes generales. Esto es un error en tanto en cuanto, se debe de poder establecer el coste, sea cual sea, de la gestión del modelo  Es habitual que se considere asumido en los diferentes proyectos el coste de participar en la certificación. Esto crea dos errores o desviaciones: o El proyecto en curso tiene que asumir un coste adicional o No se contabilizan los costes reales  Es habitual realizar unos procesos temporales para pasar la certificación de manera satisfactoria. Estos procesos no incluyen herramientas semiautomáticas o automáticas que facilitan tanto el proceso de certificación como la fase posterior: o Herramientas para automatizar las revisiones “peer review19” o Herramientas para automatizar la actualización de los planes de proyecto con coste asociado. Amortización Métricas importantes para poder evaluar cómo se amortiza la inversión realizada a nivel interno y externo. 1. Amortización interna: deben de controlar los costes internos  Debido a la falta de especificación clara de las métricas, se pueden llegar a declarar proyectos conseguidos por el efecto diferenciador, cuando realmente no lo son. Esto falsea los datos aun cuando esta métrica suele ser muy utilizada por la alta dirección. 19 Peer-review: revisión por pares http://es.wikipedia.org/wiki/Revisión_por_pares método usado para validar trabajos escritos y solicitudes de financiación con el fin de medir su calidad 17 considerados amortizados. 2. Amortización externa, entre los que se encuentran:  Efecto diferenciador: proyectos que se pueden conseguir por disponer de la certificación.  Acceso a áreas de negocio nuevas.  En cuanto al acceso a diversas propuestas de proyecto al disponer de la certificación, este suele ser claro y no hay errores. Reducción de errores Factores que indican los ratios de mejora en los proyectos de desarrollo software, p.ej.: 1. Numero de errores por área. Este factor es importante y se dispone en la mayoría de organizaciones 2. Fase de identificación de errores. Aunque puede estar implícito, se debe realizar una definición detallada de las fases 3. Peticiones de cambio debido a errores de implementación. Normalmente no se dispone de valores, pero es uno de los que se deben añadir a las métricas  Estas métricas son las que siempre se suelen comparar, incluso en exceso. Gestión de proyecto Una gran parte de las métricas van a estar centradas en la medida de progresión de proyecto de una manera objetiva. Son habituales el cálculo periódico de los siguientes valores de gestión de proyecto20: 1. CPI21: Cost Performance Index 2. BAC22: Budget at Completion 3. PV23: Planned Value 4. AC24: Actual Cost 5. EV25: Earn Value 6. EAC26: Estimate at Completion 7. ETC27: Estimate to Complete  Aunque estas métricas también se disponen en todos los proyectos, es complicado realizar comparaciones debido a las variaciones que pueden surgir de diversas situaciones especiales en los proyectos. Por ello es necesario realizar tareas tras la finalización de los proyectos (o tras la finalización de cada fase) para realizar el análisis correspondiente. Este análisis es complicado de realizar por las numerosas tareas encomendadas y es aquí en donde el equipo ejecutivo necesita hacer hincapié para que se realicen los estudios en cuestión. 20 http://en.wikipedia.org/wiki/Earned_value_management Técnica para evaluar el progreso de un proyecto de manera objetiva al obtener los datos de manera objetiva. 21 CPI: http://en.wikipedia.org/wiki/Consumer_price_index 22 BAC: http://es.wikipedia.org/wiki/BAC 23 PV: http://es.wikipedia.org/wiki/Gestión_de_proyectos 24 AC: http://en.wikipedia.org/wiki/Earned_value_management 25 EV: http://en.wikipedia.org/wiki/Earned_value_management 26 EAC: http://en.wikipedia.org/wiki/Earned_value_management 27 ETC: http://en.wikipedia.org/wiki/Earned_value_management 18 Gestión de Alta Dirección Aunque no haya una métrica específica, si es recomendable definir la información de los informes ejecutivos: contenido, periodicidad, etc. que se van a transmitir a la alta dirección. Quizás el punto más importante es si la información ejecutiva que se transmite se realiza separada o integrada en los informes actuales.  En grandes organizaciones se realizan informes ejecutivos por cada área o subárea que tenga entidad propia para realizar métricas a dicho nivel. Normalmente esos informes se consolidan para generar los informes finales de Alta Dirección. Definición del modelo Descripción Un aspecto que es realmente importante es la elección del modelo a elegir. Como ya se ha descrito en el primer capítulo del presente documento, es complicado encontrar un modelo que cubra todos los aspectos de una organización. Es por ello que otro eje importante del análisis es la elección del modelo que mejor se adapte a la organización y a los objetivos que se pretenden alcanzar. Puntos a analizar Consideraciones comunes Áreas a cubrir Determinar las áreas que se quieren cubrir con la implementación del modelo en base a los objetivos: 1. Gestión de proyecto 2. Gestión de la configuración 3. Gestión de calidad total 4. Principios de planificar-hacer- chequear-actuar. En base a esto se debe seleccionar una lista previa para realizar el análisis.  Es habitual que algún responsable de metodología o calidad proponga la implementación de un sistema de calidad solo porque: o la competencia lo va a implementar o en otras industrias funciona o etc. Es realmente importante hacer un pre análisis para limitar la lista de modelos a 2 o 3 de manera que el resto del análisis se enfoque a dichos modelos Impacto en proyectos actuales y/o futuros Este punto es importante porque servirá para realizar un buen pre análisis. El análisis de este punto debe incluir los siguientes aspectos a nivel organizativo: 1. Ciclo de vida de los proyectos 2. Plan de releases 3. Gestión de configuración  Esto es algo que no se analiza de forma correcta. Es realmente importante el incluir toda la gestión de desarrollo en el análisis para comprobar si los modelos encajan adecuadamente. Tipología de cambios de requerimientos Dependiendo del mercado o simplemente de los departamentos  Este punto se olvida a menudo siendo crucial para la adopción de modelos de calidad. Si se decide implementar un modelo concreto debe ser una decisión 19 encargados de la gestión del negocio “core28”, existen algunos aspectos que hay que considerar: 1. Velocidad de cambio: significa el número de cambios de requerimientos a lo largo del periodo definido de entregas en la organización. 2. Tipología de proyectos a realizar. Se debe tener claro si se mantiene una metodología basada en entrega iterativa y desarrollo incremental (agile29) o entrega secuencial (waterfall30) global para evitar que posteriormente se quiera cambiar la metodología. Este cambio puede hacer perder toda la inversión realizada por incompatibilidad. 3.1.1 Conclusiones Una vez considerados todos los aspectos planteados anteriormente, se debe realizar el análisis conjunto de todos y cada uno de los datos. Para ello se recomienda la realización de los documentos de análisis correspondientes por área (anteriormente descritos) y la creación de una matriz DAFO31 para la ayuda a decisión en la Alta dirección. Es realmente importante que la fase de análisis se realice con mucha rigurosidad y con unos plazos adecuados. La inversión, la excelencia y el propio negocio “core” de la organización pueden verse seriamente afectados sin la rigurosidad necesaria. # Documentos a obtener 1 Matriz DAFO como resumen ejecutivo de la fase de análisis. 2 Documento de Impacto en la organización: análisis y conclusiones 3 Documento de métricas: definición y valores históricos 4 Documento de modelos y procesos: análisis de conveniencia y matriz de definición de procesos vs procesos actuales 28 Core: principal, denominación de algo central 29 http://en.wikipedia.org/wiki/Agile_software_development 30 http://en.wikipedia.org/wiki/Waterfall_model 31 http://es.wikipedia.org/wiki/DAFO metodología de estudio de la situación competitiva de una empresa en su mercado (situación externa) y de las características internas (situación interna) de la misma, a efectos de determinar sus Debilidades, Oportunidades, Fortalezas y Amenazas Resultados recomendados 20 3.2 Proceso de certificación (SCAMPI) Fases del proceso Descripción El proceso de certificación consta de 2 partes, una preliminar en donde se realiza la evaluación de la situación actual de la organización y otra en la que se realiza la evaluación final para determinar si se cumplen los requerimientos para confirmar el nivel de certificación evaluado:  SCAMPI-B: proceso de certificación preliminar  SCAMPI-A: proceso final de certificación. Ambos procesos se realizan de igual manera: 1. Reunión de la persona certificadora con el equipo de mejora continua 2. Introducción y explicación del proceso de evaluación. 3. Preparación de la documentación generada en los proyectos para su evaluación. 4. Revisión de la documentación por el evaluador 5. Reuniones con una representación del proyecto 6. Evaluación final Puntos a analizar Consideraciones comunes Reunión del evaluador con el equipo de mejora continua El evaluador realiza una descripción del proceso a todo el equipo de mejora continua de manera que sean los miembros de este equipo sus interlocutores con los proyectos seleccionados para su evaluación. Esta reunión sirve también para clarificar temas que por alguna razón puedan no estar claros tomando en cuenta las características de la organización evaluada.  Es muy importante que el equipo de mejora continua sea en su conjunto el mismo que vaya a continuar posteriormente al proceso de certificación. De esta manera se facilita la gestión de mantenimiento o revisión de la certificación y la preparación para una futura actualización a un nivel superior.  Los proyectos a evaluar deben seleccionarse teniendo en cuenta: o La fase del proyecto en la que se encuentran. Es importante no interferir en fases críticas del mismo: diseño, pruebas finales o paso a producción. o El equipo del proyecto puede afrontar el sobreesfuerzo del proceso de certificación. Este punto es importante debido a que existen proyectos que por su naturaleza: tecnología, plazos, localización, etc. no es posible afrontar el sobreesfuerzo requerido lo cual provoca que la evaluación no sea fiel a la realidad, que el proyecto se resienta o ambas cosas. o La tipología del proyecto debe ser lo más genérica al resto de proyectos de la organización. Este punto es Factores a considerar en la proceso de certificación 21 importante ya que los procesos y herramientas que se puedan realizar deberán ser reutilizadas por el resto de proyectos una vez se adecuen a la certificación.  Es realmente crítico que todas las personas involucradas en el proceso de certificación hayan realizado algún tipo de formación, relacionada con el modelo elegido, en el que se les faciliten: objetivos de la organización (excelencia), procesos, papel de cada persona en el proceso y plazos entre otros.  Como en la realidad es complicado que todas las personas hayan realizado una mínima formación, es realmente crítico que las personas del equipo de mejora continua si hayan tenido una formación y un tiempo para tener un vasto conocimiento de la metodología antes de comenzar el proceso de certificación Introducción al proceso de evaluación El evaluador realiza una reunión de apertura en la que describe a todas las personas participantes en el proceso, realmente todas las personas del proyecto evaluado, puntos de interés a seguir durante los días de evaluación. Entre los puntos a considerar hay que resaltar: 1. Plan de la evaluación incluyendo: a. Tipo de la evaluación y sus consecuencias: SCAMPI-A o SCAMPI-B. b. Plan de reuniones. Aquí se hará hincapié en el tipo de reuniones por nivel y según perfiles de responsabilidad. c. Plan de entrega de documentación d. Interlocutores del proceso. Y logística del proceso 2. Nivel de certificación que se quiere conseguir y los procesos que se van a evaluar en base a CMMi. Este punto es importante ya que ayudara a todas las personas 3. Criterios de evaluación final  Este punto es importante principalmente para que todas las reuniones y los planes de la certificación y los proyectos se puedan ajustar para evitar situaciones de aplazamientos de reuniones o mesas de trabajo por falta de ajuste de las agendas (hay que tener en cuenta que el periodo de certificación es realmente corto: varios días, por lo que no hay mucho margen de aplazamiento.  Un punto importante es el relacionado con las reuniones que se realizan por nivel en el que el evaluador elige al azar a personas del mismo nivel dentro del proyecto para realizar preguntas acerca del día a día de trabajo. Hay que considerar que uno de los mayores problemas, o desajustes, se produce cuando en reuniones diversas se habla de algunos procesos concretos de forma diferente, lo cual muestra que el proceso no está maduro, que falta formación o que no se sigue con la rigurosidad necesaria. Todas estas discrepancias hacen que el resultado de la evaluación de dicho proceso sea negativa y por consiguiente el rechazo de la consecución del nivel CMMi al que pertenece dicho proceso. 22 Preparación de documentación Durante esta fase, el equipo de mejora continua facilita al evaluador toda la información necesaria para cada proceso a evaluar.  La entrega de documentación no es la entrega de una memoria USB con una pila de documentos de cientos de páginas (como se piensa habitualmente). El mero hecho de la entrega debe mostrar al evaluador la gestión de documentación que se sigue: control de versiones, tipos de accesos, responsable por documento, etc. Por ello esta fase es importante para comenzar a mostrar que se siguen unos procesos claros, conocidos por todas las personas del proyecto y que cumplen los criterios básicos de CMMi. Revisión de la documentación El proceso de revisión se realiza de manera concienzuda tomando en consideración: 1. Definición de responsables de cada documento y el proceso de actualización en caso de ausencia. 2. Información coherente entre los diferentes documentos. Aquí se incluye tanto planes, tareas y personas, como datos financieros del proyecto, actas de reuniones, reporte de estado de proyecto, etc. 3. Conocimiento por parte del equipo de la documentación y responsables de cada área/proceso de CMMi 4. Validación, sin previo aviso y en los puestos de trabajo diarios, del seguimiento de los documentos 5. Seguimiento de plantillas entre diferentes proyectos 6. Proceso definido para identificar puntos de mejora.  Uno de los mayores problemas con los que se encuentra una organización evaluada que o bien no ha seguido unos procedimientos estrictos o son procesos inmaduros, es el de la consistencia de la información y procesos. CMMi evalúa que existen unos procesos perfectamente sincronizados y engrasados que evitan errores típicos: o Petición de cambio actualizada en el plan pero no en el control de horas y tareas por persona o Ausencia del responsable del Plan de configuración32 sin que haya un sustituto definido o Conocimiento de todas las personas de todos los procesos en los que están involucrados o Procesos alternativos en grupos de trabajo reducido. Esto se produce por diversas razones:  Resistencia al cambio por el sobre trabajo que se genera  Antiguas experiencias que evitan la adaptación a una nueva forma de trabajar  Simple desconocimiento Reuniones con las personas de los proyectos Esta fase es realmente importante porque se realiza la comprobación de que todo lo plasmado en la documentación entregada es el “modus operandi” en el día a día.  Esta fase es otra fase importante porque como ya se ha comentado en el punto anterior, el grupo debe ser una maquina perfectamente engrasada. Esto solo es posible si todas las personas de la organización trabajan con los mismos procesos y objetivos. 32 Comúnmente llamado CM Plan: Configuration Management Plan 23 Aquí existen reuniones de diversos tipos: 1. Responsables de áreas de procesos concretas p.ej.: responsable del Plan de configuración (CMPlan) 2. Por nivel: en el que se habla de los procesos desde el responsable del proyecto hasta la última persona incorporada.  Uno de los grandes problemas a la hora de trabajar siguiendo los estándares, o procesos, de cualquier modelo es que todas las personas deben conocer los procesos, trabajar de la misma manera y utilizar las herramientas facilitadas. Es muy habitual que en cada proyecto se pueda dar más importancia a uno u otro proceso siendo el comienzo de diferencias que pueden derivar que en un periodo espacio de tiempo la divergencia sea tal que: o Una revisión de la certificación seria suspendida o Un nuevo proyecto con gente proveniente de proyectos que han aplicado de manera diferente los procesos no consiga los resultados esperados. Evaluación final y conclusiones La evaluación final se realiza por parte del evaluador en donde expone los resultados finales por proceso y nivel de certificación. Solo en el caso de que todos los procesos se sigan de manera satisfactoria se consigue la certificación. Asimismo siempre se producen recomendaciones según las necesidades de la organización en cuestión.  Aquí el punto realmente importante es el convencimiento y la voluntad para afrontar el mantenimiento de todos los procesos junto al equipo de mejora continua para que se produzca el seguimiento requerido.  Una acción que se ve en diversas organizaciones es la relajación tras la certificación. Esta relajación se muestra en: o Desmantelamiento del equipo de mejora continua o Disminución de los niveles de exigencia en los procesos o Adopción parcial de los procesos, incluso despreciando algunos. 3.2.1 Conclusiones La fase de implementación es fundamental para conseguir la certificación en el modelo deseado. Este hecho no puede esconder la necesidad imperiosa de utilizar esta fase para identificar mejoras, automatizaciones, simplificaciones de procesos y recibir comentarios de las personas que trabajan día a día en los proyectos. Asimismo, la creación del equipo de mejora continua tiene un aspecto fundamental para que sirva de engranaje en todo el proceso de implementación del modelo de calidad. 24 # Documentos a obtener 1 Evaluación final: tanto a nivel ejecutivo como a nivel de detalle 2 Documento de modelos y procesos: actualización de la versión creada como parte del análisis. 3 Documento de métricas: actualización según modificaciones de los procesos 4 Documento de seguimiento: descripción del proceso de certificación. Útil de cara a futuras revisiones o certificaciones. 3.3 Proceso de mejora continua o mantenimiento Evaluación de la extensión Descripción Una vez que se ha conseguido la certificación, e independientemente del nivel conseguido, el equipo de mejora continúa es el responsable de realizar las tareas de control y definición del proceso de extensión de la certificación al resto de la organización. Durante esta fase se definen varias acciones de vital importancia en el proceso de extensión del modelo al resto de la organización. Puntos a analizar Consideraciones comunes Definición del alcance de la extensión de la certificación El equipo de CMMi debe definir el plan de extensión definitivo. Para ello utilizara como apoyo los resultados tanto de la fase de análisis como de la fase de certificación.  Importante el utilizar los resultados del proceso de certificación para la definición del alcance. Esto se debe a que pueden existir procesos que a priori pueden parecer perfectamente compatibles con el modelo y tras el proceso de certificación se puede ver que solo funcionan correctamente en un área o un tipo de proyecto concreto p.ej: los procesos no se utilizan igual en proyectos de desarrollo o proyectos de mantenimiento. Definición del impacto organizativo En paralelo a la creación del plan de extensión se debe de realizar una revisión del impacto organizativo por si los resultados previos, de la fase de análisis, tuvieran que sufrir alguna modificación debido a un posible cambio de los procesos.  Aspecto importante ya que puede surgir la necesidad de que un área concreta sea la responsable de ciertos procesos o la revisión de los mismos p.ej.: en los proyectos se puede compartir equipos: soporte técnico, pruebas, etc. lo cual puede obligar a que ese equipo común deba tomar la responsabilidad de dicha área con el consiguiente impacto organizativo y de planificación en la extensión. Resultados recomendados Factores a considerar en la fase posterior a la certificación 25 Evaluación del impacto en proyectos actuales y futuros El plan de expansión debe considerar el plan de proyecto de todos y cada uno de los que pueden verse impactados llegando incluso a tener que tomar la decisión de que un proyecto no participe en la extensión o se retrase al comienzo de una iteración planificada.  El querer aplicar un plan sin ver las particularidades de cada proyecto es uno de los errores más comunes. Procesos de mejora continua Descripción En paralelo a las tareas de control y definición del proceso de extensión se debe realizar la planificación de las tareas de mejora. Estas tareas de mejora se identifican principalmente durante el proceso de certificación y tienen como objetivo el automatizar o facilitar el seguimiento de los procesos definidos. Puntos a analizar Consideraciones comunes Documentación de procesos Como resultado del proceso de certificación es necesario realizar una actualización de la documentación. Esta tarea debe incluirse como parte del plan de expansión.  Es habitual que esta tarea no se haga con la rigurosidad necesaria debido a dejadez o falta de motivación tras el proceso de certificación. Creación, o evaluación, de herramientas Tarea fundamental para ayudar en el día a día a los proyectos. Cualquier automatización o simplificación en el seguimiento de procesos es fundamental para obtener mejores métricas y mantener el nivel de completitud de los procesos.  El mayor problema es la inexistencia de herramientas en el mercado que faciliten esta tarea. Es habitual que las herramientas se construyan en cada organización p.ej: control de revisiones en web, control de tareas y horas común, etc. Definición de plan de objetivos Plan realizado a corto plazo: 2 o 3 años para conseguir los objetivos marcados.  La implementación de un modelo de calidad debe formar parte de la estrategia de IT a corto plazo. De ahí que sea básico que el plan del modelo: fechas importantes, dependencias, etc. Estén incluidos en el plan estratégico de la organización.