People CMM para gestionar los factores que influyen en la mejora de procesos de software

Transcripción

1 Universidad ORT Uruguay Facultad de Ingeniería People CMM para gestionar los factores que influyen en la mejora de procesos de software Entregado como requisito para la aprobación del Master en Ingeniería María Jimena Saavedra Tutor: Dr. Gerardo Matturro 2012

2 Abstract En la literatura acerca de la mejora de procesos de software se identifican factores de éxito y de resistencia que influyen en tales iniciativas. A lo largo de este trabajo se analizan posibles acciones a nivel organizacional para poder gestionarlos a través de las áreas de proceso del modelo People CMM. La implementación de las mejoras en las prácticas y procesos de software es un caso particular de cambio organizacional y como en cualquier cambio, los recursos humanos o fuerza laboral son generalmente un parámetro clave para que este cambio sea exitoso. Es en este aspecto, que el modelo People CMM es una guía para implementar prácticas de gestión de recursos humanos que contribuyen a mejorar continuamente la capacidad de la fuerza de trabajo de una organización. A partir de un análisis de la literatura se han identificado factores de éxito, barreras, motivadores y desmotivadores que han sido agrupados en categorías basados en similitud de conceptos que subyacen en cada factor. Estas categorías de factores han sido contrastadas con entrevistas realizadas a dos empresas de software uruguayas que han implementado prácticas de mejora de procesos de software. A su vez se han identificado qué acciones han tomado éstas para gestionarlas. Estas categorías conjuntamente con las acciones han sido mapeadas con las prácticas del People CMM de forma de identificar las áreas de proceso de este modelo que ayudan a que las mejoras de proceso de software implementadas en una organización perduren en el tiempo exitosamente, fortaleciendo los factores de éxito y motivadores y mitigando los factores de resistencia. Como resultado de este trabajo, de las 22 áreas de proceso de People CMM, el estudio realizado muestra que 13 de estas áreas de proceso se enfocan en prácticas cuya implementación contribuye a gestionar los factores que inciden positiva y negativamente en las iniciativas de mejora de procesos software. Por otro lado también se observa que el People CMM aparenta no contribuir o contribuir parcialmente en 6 categorías de factores que de acuerdo al estudio tienen implicancia en la implementación de las iniciativas de mejora de procesos de software. Otro hallazgo del estudio también indica que 4 categorías de factores se gestionan con la implementación del modelo CMMI. 2

3 Índice 1 Introducción Propósito y finalidad de la tesis Estructura de la tesis Aportes de la tesis El Modelo CMMI CMMI para desarrollo Representaciones del CMMI Arquitectura del CMMI representación por etapas o escalonada El grupo de adiciones de integración del proceso y del desarrollo de producto (IPPD) Nivel de Madurez 1 Inicial Nivel de Madurez 2 Gestionado Nivel de Madurez 3 Definido Nivel de Madurez 4 Gestionado Cuantitativamente Nivel de Madurez 5 En Optimización

4 2.3.7 Prácticas de Institucionalización del CMMI El Modelo People CMM Nivel 1 Inicial Nivel 2 Administrado Nivel 3 Definido Nivel 4 Predecible Nivel 5 - Optimizado Representaciones del People CMM Prácticas de Institucionalización e implementación del People CMM Trabajos Relacionados Trabajos basados en la visión personal del individuo involucrado en la mejora de proceso de software Trabajos basados en la visión de la organización dueña de la mejora de proceso de software Categorización de Factores Relación de categorías de factores con las áreas de proceso del People CMM Importancia de la implementación de prácticas de institucionalización Diseño Metodológico

5 7.1 Problema de Investigación Procedimientos y Técnicas Cuestionarios Entrevistas Ámbito de la realización del estudio Las organizaciones Informantes clave Recolección de Datos Análisis y Evaluación de los resultados del estudio Tendencia de actitud de las valoraciones de las categorías Resultados obtenidos por categoría Comparación entre la priorización de factores encontrados en la literatura y la frecuencia de mención de los factores reportados por los entrevistados Relación entre acciones reportadas y áreas de proceso del People CMM Conclusiones del Estudio Conclusiones de la tesis Restricciones del Estudio

6 10 Futuros Trabajos Bibliografía Anexo A Planillas de registro de entrevistas Anexo B Planillas auxiliares de conteo Anexo C Resumen de Respuestas a entrevistas

7 1 Introducción A partir del año 2000, las empresas de software uruguayas se han visto en la necesidad de posicionarse estratégicamente mejor en los mercados tanto locales como del exterior desde el punto de vista de los productos y procesos que desarrollan. En primera instancia el mercado de empresas que precisan del desarrollo de software ha elevado su barrera de acceso y comenzaron a exigir determinados estándares de calidad en los productos y procesos de las empresas proveedoras de software. Es así que muchas empresas de software uruguayas, para poder acceder a estos mercados tan exigentes, debieron adquirir e implementar mejores prácticas de la industria de desarrollo de software. En segunda instancia algunas empresas uruguayas que pertenecen a organizaciones multinacionales se vieron también obligadas por sus oficinas centrales a alinearse con los estándares de calidad ya adoptados por éstas. Por último, existen aquellas empresas que en base a los resultados de sus operaciones deciden mejorar sus procesos y productos para optimizar sus ciclos de desarrollo y cumplir con las expectativas de sus clientes. Sin embargo, la implementación de estas buenas prácticas, son realizadas por personas, es decir por la fuerza laboral de las organizaciones. Un modelo tomado por algunas empresas uruguayas de software para mejorar sus procesos de desarrollo es el Capability Maturity Model Integration For Development (CMMI for Dev.), de ahora en más llamado CMMI en este documento, patrocinado por el Software Engineering Institute (SEI) de la Universidad de Carnegie Mellon. Este modelo sugiere buenas prácticas que se enfocan en actividades de desarrollo y mantenimiento aplicado a productos y servicios (Chrissis, Konrad et al. 2006). Si bien el CMMI contiene algunas prácticas respecto a cómo implementar procesos de entrenamiento para las personas que ejecutarán los procesos puedan realizarlo satisfactoriamente, no es su fin concentrarse en aquellas buenas prácticas para la mejora de capacidades de las personas que trabajan en una organización ni tampoco es su foco estudiar la cultura organizacional de la empresa que va a implementar esas mejoras. Sin embargo, existen ciertas prácticas adicionales del CMMI que permiten tener una mejor colaboración por parte de los involucrados claves en el ciclo de vida del producto para poder satisfacer necesidades, expectativas y requerimientos. Estas prácticas adicionales se conocen como prácticas de desarrollo de productos y procesos integrados (IPPD) (Sanchez 2006). No obstante estas prácticas son opcionales y no existe su implementación al momento en las industrias de software uruguayas ni tampoco estas prácticas se orientan a mejorar la influencia 7

8 de las personas en la mejora de los procesos. Por otro lado el CMMI presenta prácticas de institucionalización para minimizar el riesgo de que los cambios implantados no perduren en el tiempo, sin embargo, aún implementándolas muchas de las oportunidades de mejora fallan dado que solo algunas se enfocan en las personas que ejecutan el trabajo. Cuando todavía se encontraba vigente el modelo Capability Maturity Model (CMM), precursor del CMMI, en las clases de introducción a este modelo existía una ilustración que constaba de un asiento de tres apoyos. La parte del asiento representaba la organización. Uno de los apoyos representaba la tecnología, el otro los procesos y el tercer apoyo las personas. Lo que este gráfico pretendía representar es que para poder tener una organización estable, los tres apoyos debían estar presentes y que con la ausencia de uno, el asiento podía caer. Sin embargo una de los apoyos más olvidados a la hora de implementar mejoras a los procesos de software es el de las personas (Kulpa 2007). La ilustración 1.1 muestra lo explicado anteriormente. Ilustración 1.1 Los 3 apoyos de una organización En base a lo descrito anteriormente, el Software Engineering Institute, patrocinador del CMMI, ha propuesto un modelo orientado a la mejora de la capacidad ( capability ) de la fuerza laboral de una compañía. Este modelo se conoce como People Capability Maturity Model (PCMM). La capacidad de la fuerza laboral ( workforce ) se define como el nivel de conocimientos, destrezas y habilidades de proceso disponibles para desempeñar las actividades de negocio de una organización (Curtis, Hefley et al. 2003). Si bien no existe en el modelo People CMM un área de proceso que contemple el desarrollo de una cultura organizacional orientada a sustentar las iniciativas de cambio organizacional como la que supone CMMI, se enfatiza el concepto a lo largo del mismo y su importancia a la hora de gestionar las capacidades de la fuerza laboral. 8

9 Por otro lado, para que una implementación de mejoras se institucionalice, existen factores que facilitan esta implementación y barreras que retrasan o impiden la misma, tanto desde el punto de vista individual como organizacional. A lo largo de este trabajo de tesis se podrá observar el siguiente proceso de investigación: Se han identificado factores tanto individuales como organizacionales que incluyen tanto positiva como negativamente en la implementación de mejoras de procesos de software. Estos factores surgen de una revisión de la literatura y posteriormente agrupados en categorías. Consecuentemente se realizó un mapeo inicial de estas categorías con las áreas de proceso del People CMM de forma de encontrar cuáles podrían aportar a una implementación exitosa de las iniciativas de mejora de procesos de software. Se realizó un estudio de campo en dos empresas de software que han llevado a cabo iniciativas de mejora para determinar las categorías de factores que estas empresas consideraron más importantes, y las acciones tomadas por ellas para gestionarlos. En base a estas entrevistas y con la información analizada se procedió nuevamente a revisar cuáles áreas del People CMM favorecen o desfavorecen la implementación de las mejoras. Por otro lado también se compararon las categorías encontradas en la literatura y las obtenidas durante las entrevistas para ver si existieron similitudes y cuál fue su orden de importancia. 1.1 Propósito y finalidad de la tesis El propósito de esta tesis es realizar un aporte al estado de la práctica de la implementación de mejoras de procesos de software en lo relativo a la gestión de aquellos factores personales y organizacionales que tienen influencia en una iniciativa de mejora de procesos. La finalidad es explorar en qué medida el modelo People CMM es adecuado para gestionar los factores que inciden en las iniciativas de mejora de procesos software, particularmente las basadas en el modelo CMMI. 9

10 1.2 Estructura de la tesis En los capítulos 2 y 3 se procede a la explicación de los modelos CMMI y People CMM, los cuales son mencionados a lo largo del trabajo. El capítulo 4 realiza una revisión de la literatura. Ésta tuvo como finalidad la identificación de los factores de éxito, barreras, obstáculos, motivadores y desmotivadores reportados en la literatura. El capítulo 5 realiza una agrupación de estos factores en categorías. La necesidad de agrupar en categorías surgió por la gran cantidad de factores identificados que correspondían a un mismo patrón. De forma de simplificar su identificación es que se decidió agrupar en categorías. A su vez facilitó posteriormente al mapeo con las áreas de proceso del modelo People CMM. En el capítulo 6 se realiza un análisis inicial de la relación de estas categorías con las áreas de proceso del People CMM que podrían llegar a favorecer su implementación. El capítulo 7 muestra el diseño metodológico de la tesis, estableciendo el problema de investigación, las técnicas y procedimientos aplicados, el ámbito de las organizaciones que forman parte de las encuestas realizadas entre otros aspectos. En el capítulo 8 se realiza el análisis y comparación de resultados. Se muestra la comparación de las categorías de factores resultantes de la revisión de la literatura y aquellos detectados en las entrevistas. Durante las entrevistas también se consultó qué prácticas han implementado para que estos factores se potencien o mitiguen. Éstas fueron luego comparadas con las sugeridas por el People CMM y ver si existe algún tipo de relación. En el capítulo 9 se realizan las conclusiones del estudio, donde del análisis comparativo de la literatura con las categorías resultantes de las entrevistas, surge que el compromiso de la alta gerencia es una de las 5 categorías más importantes y que la asignación de personal con habilidades, conocimientos y experiencia es otras de las categorías más importantes. El análisis de los resultados de las entrevistas permiten sugerir que el área de proceso Cultura de Participación del nivel 3 del People CMM aparenta ser la que más categoría de factores cubre y que las áreas de proceso Comunicación y Coordinación y Contratación del nivel 2 del People CMM aparecen como las siguiente en relevancia para favorecer la implementación de 10

11 las mejoras de proceso de software. A su vez también en este mismo orden aparece el área de proceso Análisis de Competencias del nivel 3. En el nivel 4 del People CMM contamos con el área de proceso Grupo de Trabajos Autónomos. También del análisis se puede observar que el People CMM aparenta no contribuir o contribuir parcialmente en el éxito de algunas categorías de factores. En el Anexo A, se incluyen los cuestionarios desarrollados para las entrevistas. En el Anexo B se muestran las planillas auxiliares que se utilizaron para contabilizar los resultados de las entrevistas. 1.3 Aportes de la tesis Los aportes realizados con esta tesis son: 1. Una visión general de los conceptos de los modelos CMMI y People CMM como marcos de referencia. 2. Una revisión de la literatura donde se identifican los factores de éxito, barreras, obstáculos, motivadores y desmotivadores que influyen en una iniciativa de mejora de procesos software. 3. Una guía para que las organizaciones al enmarcarse en la iniciativa de mejoras de procesos de software tengan en cuenta los aspectos individuales y organizacionales que tienen influencia en dicha implementación. 4. Un conjunto de recomendaciones sobre qué áreas de proceso del PCMM implementar como las más relevantes en cuanto a su influencia en la mejora de procesos de software, provenientes de las encuestas y análisis realizados. 11

12 2 El Modelo CMMI Los CMM se concentran en la mejora de los procesos de una organización. Contienen los elementos esenciales de eficacia de los procesos en una o más disciplinas y describen un camino de mejora evolutivo que permite pasar desde procesos inmaduros ad hoc a procesos disciplinados y maduros de mejor calidad y más eficaces (Chrissis, Konrad et al. 2009). El Software Engineering Institute (SEI) creó el primer CMM concebido para organizaciones de desarrollo de software y lo publicó en un libro, The Capability Maturity Model: Guidelines for improvement the Software Process (SEI 1995). Desde 1991, los CMM se han desarrollado para innumerables disciplinas. Algunas de las más notables comprenden modelos para la ingeniería de sistemas, la ingeniería del software, la adquisición del software, el desarrollo y la gestión del personal, y el desarrollo integrado de productos y procesos (IPPD) (Chrissis, Konrad et al. 2009). Aunque estos modelos han probado ser útiles para muchas organizaciones en el seno de diferentes industrias, el uso de múltiples modelos ha sido problemático. Muchas organizaciones quisieran extender sus esfuerzos de mejora a diversos grupos en sus organizaciones. Sin embargo, las diferencias entre los modelos de disciplinas específicas utilizados por cada grupo, incluyendo su arquitectura, contenido y aproximación, han limitado las capacidades de estas organizaciones para generalizar con éxito sus mejoras. Además, la aplicación de múltiples modelos no integrados en y a través de una organización es costosa en términos de formación, de evaluaciones y de actividades de mejora. El proyecto de integración de CMM ha sido realizado para regular el problema de utilizar múltiples CMM. La misión inicial del equipo del producto CMMI (CMMI Product Team) fue combinar tres modelos fuente: Capability Maturity Model for Software (SW-CMM) v2.0 Systems Engineering Capability Model (SECM) Integrated Product Development Capability Maturity Model (IPD-CMM) v

13 Estos tres modelos fuente fueron seleccionados debido a su extensa adopción por las comunidades de desarrollo de sistemas y de software y también porque proponen diversos acercamientos a la mejora de procesos en el seno de una organización. CMMI es el sucesor de estos tres modelos y se puede definir como un modelo de mejora de mejora de madurez para el desarrollo de productos y servicios. Consta de las mejoras prácticas de desarrollo y mantenimiento que cubren el ciclo de vida desde la concepción, liberación y mantenimiento. (Chrissis, Konrad et al. 2006) En la Ilustración 2.1 se puede observar la evolución de los CMMs Ilustración 2.1 Historia de los CMMs (Chrissis, Konrad et al. 2009) A su vez, el CMMI ha sufrido varios cambios desde su nacimiento, generando así varias versiones del modelo. Su arquitectura fue mejorada para poder soportar también múltiples constelaciones y para compartir varias mejores prácticas entre éstas. Una constelación es una colección de componentes CMMI que incluyen un modelo, materiales de entrenamiento y documentos relacionados a la evaluación de un área de interés. 13

14 Actualmente existen 3 constelaciones que soporta la versión 1.2 del modelo: desarrollo (CMMI-DEV), servicios (CMMISVC) y adquisición (CMMI for Acquisition). Este trabajo de tesis se enfocará en la constelación para desarrollo (CMMI-DEV) para su versión 1.2. Actualmente está vigente la versión 1.3 del modelo, como resultado de la revisión realizada por el Comité de Dirección. Esta nueva versión moderniza practicas de niveles de madurez 4 y 5 como también otras actualizaciones mejores para las 3 constelaciones (Phillips 2010). 2.1 CMMI para desarrollo CMMI para desarrollo es un modelo de referencia que cubre las actividades del desarrollo y del mantenimiento aplicadas tanto a los productos como a los servicios. Las organizaciones de numerosas industrias, incluyendo la aeroespacial, los bancos, la construcción de ordenadores, el software, la defensa, la fabricación del automóvil y las telecomunicaciones, utilizan el CMMI para desarrollo. Los modelos de la constelación del CMMI para desarrollo contienen prácticas que cubren la gestión de proyectos, la gestión de procesos, la ingeniería de sistemas, la ingeniería del hardware, la ingeniería de software y otros procesos de soporte utilizados en el desarrollo y el mantenimiento (Chrissis, Konrad et al. 2009). 2.2 Representaciones del CMMI El CMMI le permite aproximarse a la mejora de procesos y a las evaluaciones usando dos representaciones diferentes: continua y por etapas o escalonada. La representación continua permite a una organización seleccionar un área de proceso (o un grupo de áreas de proceso) y mejorar los procesos relacionados con ésta. Esta representación utiliza unos niveles de capacidad para caracterizar la mejora concerniente a un área de proceso individual. 14

15 La representación por etapas utiliza conjuntos predefinidos de áreas de proceso para definir un camino de mejora para una organización. Este camino de mejora se caracteriza por diversos niveles de madurez. Cada nivel de madurez proporciona un conjunto de áreas de proceso que caracterizan diferentes comportamientos organizativos (Chrissis, Konrad et al. 2009). Este trabajo de tesis se enfocará en la representación por etapas. 2.3 Arquitectura del CMMI representación por etapas o escalonada Un nivel de madurez consta de prácticas relacionadas específicas y genéricas para un conjunto predefinido de áreas de proceso que mejoran el rendimiento global de la organización. El nivel de madurez de una organización proporciona un camino para predecir el rendimiento en una disciplina dada o en un conjunto de disciplinas. La experiencia ha mostrado que las organizaciones toman la mejor decisión cuando centran sus esfuerzos de mejora de procesos en un número controlable de áreas de proceso a la vez y que dichas áreas requieren aumentar su complejidad cuando la organización mejora. Un nivel de madurez es una meseta evolutiva definida para la mejora de procesos de la organización. Cada nivel de madurez madura un subconjunto importante de procesos de la organización, preparándola para pasar al siguiente nivel de madurez. Los niveles de madurez se miden mediante el logro de metas específicas y genéricas asociadas a cada conjunto predefinido de áreas de proceso. Existen cinco niveles de madurez, siendo cada uno de ellos una capa en la cimentación de la mejora de procesos en curso, denominados por los números 1 a 5. (1) Inicial (2) Gestionado (3) Definido (4) Gestionado Cuantitativamente (5) En Optimización La Ilustración 2.2 muestra la arquitectura del modelo en su representación por etapas. 15

16 Ilustración 2.2 Arquitectura CMMI El grupo de adiciones de integración del proceso y del desarrollo de producto (IPPD) En el CMMI, las adiciones sirven para integrar el material específico que puede ser de interés a utilizadores particulares. En la constelación del CMMI para desarrollo, se ha añadido material para generar la integración del proceso y del desarrollo de producto (IPPD). El grupo de adiciones IPPD cubre una aproximación que comprende las prácticas que ayudan a las organizaciones a colaborar en tiempo útil con las partes interesadas a lo largo de la vida del producto, para satisfacer las necesidades, las expectativas y las exigencias de los clientes. Este trabajo de tesis no se enfocará en las prácticas adicionales de IPPD Nivel de Madurez 1 Inicial En el nivel de madurez 1, los procesos son generalmente ad-hoc y caóticos. La organización generalmente no proporciona un entorno estable para dar soporte a los procesos. El éxito en estas organizaciones depende de la competencia y heroicidad del personal de la organización y no del uso de procesos probados. A pesar de este caos, las organizaciones de nivel de madurez 1 a menudo producen productos y servicios que funcionan; sin embargo, frecuentemente exceden sus presupuestos y no cumplen sus calendarios. 16

17 Las organizaciones de nivel de madurez 1 se caracterizan por una tendencia a comprometerse en exceso, a abandonar los procesos en tiempos de crisis y a una incapacidad para repetir sus éxitos (Chrissis, Konrad et al. 2009) Nivel de Madurez 2 Gestionado En el nivel de madurez 2, los proyectos de la organización han asegurado que los procesos se planifican y realizan de acuerdo a políticas; los proyectos emplean personal con habilidad que dispone de recursos adecuados para producir resultados controlados; involucran a las partes interesadas relevantes; se monitorizan, controlan y revisan; y se evalúan en cuanto a su adherencia a sus descripciones de proceso. La disciplina de proceso reflejada por el nivel de madurez 2 ayuda a asegurar que las prácticas existentes se mantienen durante tiempos de estrés. Cuando estas prácticas están en su lugar, los proyectos se realizan y gestionan de acuerdo a sus planes documentados (Chrissis, Konrad et al. 2009). En la Tabla 2.1 se muestran las áreas de proceso de este nivel de madurez y sus prácticas: Áreas de Proceso Prácticas Gestión de Requerimientos 5 Planificación 14 Monitoreo y Control de Proyectos 10 Gestión de Acuerdos con Proveedores 8 Medición y Análisis 8 Aseguramiento de la Calidad del Proceso y del 4 Producto Gestión de la Configuración 7 Tabla 2.1 Áreas de Proceso y Prácticas CMMI Nivel Nivel de Madurez 3 Definido En el nivel de madurez 3, los procesos son bien caracterizados y comprendidos, y se describen en estándares, procedimientos, herramientas y métodos. El conjunto de procesos estándar de la organización, que es la base del nivel de madurez 3, se establece y mejora a lo largo del tiempo. 17

18 Estos procesos estándar se usan para establecer la consistencia en toda la organización. Los proyectos establecen sus procesos definidos adaptando el conjunto de procesos estándar de la organización de acuerdo a guías de adaptación (Chrissis, Konrad et al. 2009). En la Tabla 2.2 se muestran las áreas de proceso de este nivel de madurez y sus prácticas: Áreas de Proceso Prácticas Desarrollo de Requerimientos 10 Solución Técnica 8 Integración del Producto 9 Verificación 8 Validación 5 Enfoque en Procesos de la Organización 9 Definición de Procesos de la Organización 6 Entrenamiento Organizacional 7 Gestión Integrada de Proyectos 9 Gestión de Riesgos 7 Análisis de Decisiones y Resolución 6 Tabla 2.2 Áreas de Proceso y Prácticas CMMI Nivel Nivel de Madurez 4 Gestionado Cuantitativamente En el nivel de madurez 4, la organización y los proyectos establecen objetivos cuantitativos en cuanto al rendimiento de calidad y del proceso, y los utilizan como criterios en la gestión de los procesos. Los objetivos cuantitativos se basan en las necesidades del cliente, usuarios finales, organización e implementadores del proceso. El rendimiento de calidad y del proceso se comprende en términos estadísticos y se gestiona durante la vida de los procesos (Chrissis, Konrad et al. 2009). En la Tabla 2.3 se muestran las áreas de proceso de este nivel de madurez y sus prácticas: Áreas de Proceso Prácticas Rendimiento de Procesos de la Organización 5 Gestión Cuantitativa del Proyecto 8 Tabla 2.3 Áreas de Proceso y Prácticas CMMI Nivel Nivel de Madurez 5 En Optimización En el nivel de madurez 5, una organización mejora continuamente sus procesos basándose en una comprensión cuantitativa de las causas comunes de variación inherentes a los procesos. 18

19 El nivel de madurez 5 se centra en mejorar continuamente el rendimiento de procesos mediante mejoras incrementales e innovadoras de proceso y tecnológicas. Los objetivos cuantitativos de mejora de procesos para una organización se establecen, se revisan continuamente para reflejar el cambio a los objetivos del negocio, y se utilizan como criterios para gestionar la mejora de procesos. Los efectos de las mejoras de procesos desplegadas se miden y evalúan frente a los objetivos cuantitativos de mejora de procesos. Tanto los procesos definidos como el conjunto de procesos estándar de la organización son objeto de las actividades de mejora cuantitativa (Chrissis, Konrad et al. 2009). En la Tabla 2.4 se muestran las áreas de proceso de este nivel de madurez y sus prácticas: Áreas de Proceso Prácticas Innovación y Despliegue en la Organización 7 Análisis Causal y Resolución 5 Tabla 2.4 Áreas de Proceso y Prácticas CMMI Nivel Prácticas de Institucionalización del CMMI La institucionalización es un concepto importante en la mejora de procesos. La institucionalización implica que el proceso está enraizado en la forma en que se realiza el trabajo y existe un compromiso y una consistencia para realizar el proceso (Chrissis, Konrad et al. 2009). Es más probable mantener un proceso institucionalizado en momentos de estrés. Sin embargo, cuando los requerimientos y los objetivos del proceso cambian puede también ser necesario cambiar la implementación del proceso para asegurar que sigue siendo eficaz. Las prácticas genéricas (de institucionalización) describen las actividades que tratan estos aspectos de institucionalización. A continuación se explican cada una de las prácticas de institucionalización (Chrissis, Konrad et al. 2009): Realizar las prácticas genéricas: El propósito de esta práctica genérica es producir los productos de trabajo y entregar los servicios que se esperan por realizar el proceso. Estas prácticas se pueden hacer de manera informal, sin seguir una descripción documentada del 19

20 proceso o un plan. El rigor con que estas prácticas se realizan depende de las personas que gestionan y realizan el trabajo y puede variar considerablemente. Establecer una política de la organización: El propósito de esta práctica genérica es definir las expectativas de la organización en relación con el proceso y hacerlas visibles a aquellos en la organización que están afectados. En general, la dirección es responsable de establecer y comunicar los principios, guías, orientación y expectativas para la organización. No toda orientación de la dirección llevará la etiqueta política. Lo que se espera de esta práctica genérica es la existencia de una orientación apropiada de la organización, independientemente de cómo sea llamada o comunicada. Planificar el proceso: El propósito de esta práctica genérica es determinar lo que se necesita para realizar el proceso y para lograr los objetivos establecidos, preparar un plan para realizar el proceso, preparar una descripción del proceso y acordar el plan con las partes interesadas relevantes. Proporcionar recursos: El propósito de esta práctica genérica es asegurar que los recursos necesarios para realizar el proceso tal y como se definieron en el plan están disponibles cuando se necesiten. Los recursos incluyen financiación adecuada, instalaciones físicas apropiadas, personal cualificado y herramientas apropiadas. La interpretación del término adecuado depende de muchos factores y puede cambiar con el tiempo. Los recursos inadecuados pueden tratarse incrementando recursos o eliminando requerimientos, restricciones o compromisos. Asignar responsabilidad: El propósito de esta práctica genérica es asegurar que existe responsabilidad para realizar el proceso y lograr los resultados especificados a lo largo de la vida del proceso. Las personas asignadas deben tener la autoridad apropiada para realizar las responsabilidades asignadas. Formar al personal: El propósito de esta práctica genérica es asegurar que las personas tengan las habilidades y la experiencia necesaria para realizar o dar soporte al proceso. Gestionar configuraciones: El propósito de esta práctica genérica es establecer y mantener la integridad de los productos de trabajo designados del proceso (o de sus descripciones) a lo largo de su vida útil. 20

21 Identificar e involucrar a las partes interesadas relevantes: El propósito de esta práctica genérica es establecer y mantener la participación prevista de las partes interesadas durante la ejecución del proceso. Monitorear y controlar el proceso: El propósito de esta práctica genérica es realizar la monitorización y el control directo del proceso día a día. Se mantiene una visibilidad apropiada del proceso, por lo que se pueden tomar acciones correctivas apropiadas cuando sea necesario. Monitorizar y controlar el proceso involucra medir los atributos apropiados del proceso o de los productos de trabajo producidos por el proceso. Evaluar objetivamente la adherencia: El propósito de esta práctica genérica es proporcionar un aseguramiento creíble de que el proceso se implementó como estaba planificado y se adhiere a su descripción de proceso, estándares y procedimientos. Esta práctica genérica se implementa, en parte, evaluando los productos de trabajo seleccionados del proceso. Revisar el estado con el nivel directivo: El propósito de esta práctica genérica es proporcionar la visibilidad apropiada del proceso al nivel directivo. El nivel directivo incluye a aquellos niveles de gerencia en la organización situados por encima del nivel inmediato de gerencia responsable del proceso. En particular, el nivel directivo incluye a los directivos. Estas revisiones son para los directores que proporcionan la política y la guía global del proceso, y no para los que realizan la monitorización y el control directo diario del proceso. Establecer un proceso definido: El propósito de esta práctica genérica es establecer y mantener una descripción del proceso que se adapta a partir del conjunto de procesos estándar de la organización para tratar las necesidades de una instanciación especifica. La organización debería tener procesos estándar que cubran el área de proceso, así como guías de adaptación de estos procesos estándar para cumplir con las necesidades de un proyecto o de una función de la organización. Con un proceso definido, se reduce la variabilidad en la forma que se realizan los procesos en la organización y pueden compartirse con eficacia los activos de proceso, los datos y el aprendizaje. Recoger información de mejora: El propósito de esta práctica genérica consiste en recoger información y artefactos derivados de la planificación y realización del proceso. Esta práctica genérica se realiza para que la información y los artefactos puedan incluirse en los activos de proceso de la organización y estar disponibles para aquellos que estén (o vayan a estar) planificando y realizando procesos idénticos o similares. La información y los artefactos se almacenan en el repositorio de medición de la organización y en la biblioteca de activos de proceso de la organización. 21

22 Dependiendo del nivel de madurez que se desee implementar se realizarán diferentes prácticas genéricas. Las prácticas de Establecer un proceso definido y Recoger información de Mejora son implementadas cuando se desea alcanzar un nivel de madurez 3 o mayor. 22

23 3 El Modelo People CMM El objetivo primario del People Capability Maturity Model (PCMM ) es la mejora de la capacidad ( capability ) de la fuerza laboral. La capacidad de la fuerza laboral Workforce puede definirse como el nivel de conocimientos, destrezas y habilidades de proceso disponibles para desempeñar las actividades de negocio de una organización (Curtis, Hefley et al. 2009). Los componentes esenciales de la estructura del modelo People CMM son los siguientes: Niveles de madurez Áreas de proceso Objetivos Prácticas El modelo People CMM consiste de cinco niveles de madurez como muestra la Ilustración 3.1, o estados evolutivos, a través de los cuales evolucionan las prácticas y procesos de gestión de las capacidades de los recursos humanos de una organización. En cada nivel de madurez, un nuevo sistema de prácticas es superpuesto a aquellas implementadas en los niveles anteriores. Cada superposición de prácticas eleva el nivel de sofisticación por medio de cual la organización desarrollo su fuerza laboral. Ilustración 3.1 Niveles PCMM según (Curtis, Hefley et al. 2009) 23

24 Cada nivel de madurez, excepto el primero, tiene asociado un conjunto de áreas de proceso. Un área de proceso es un agrupamiento de prácticas que, al realizarse de forma colectiva, satisfacen una serie de metas que contribuyen a la capacidad adquirida por el logro de un nivel de madurez. El modelo People CMM tiene un total de veintidós áreas de proceso distribuidas en los cinco niveles de madurez, según se muestra en la Tabla 3.1 Tabla 3.1 Áreas de Proceso por nivel Cada área de proceso tiene asociado un conjunto de objetivos y se describe en base a un conjunto de prácticas. Un objetivo es un estado organizacional a ser alcanzado en base a la implementación de las prácticas de un áreas de proceso (Curtis, Hefley et al. 2009). Cuando los objetivos de todas las áreas de proceso incluidas en un nivel de madurez se han cumplido, la organización habrá logrado el nivel de madurez y establecido un nuevo nivel de capacidad en la gestión de su fuerza laboral. 24

25 Un área de proceso no se habrá implementado satisfactoriamente hasta que todos sus objetivos describan con precisión el comportamiento o estado de situación de la organización. Cada área de proceso se describe en términos de las prácticas que contribuyen a la satisfacción de sus objetivos. Cada área de proceso se describe en términos de las prácticas que contribuyen a la satisfacción de sus objetivos. Una práctica es un subproceso dentro de un área de proceso (Curtis, Hefley et al. 2009). Una práctica describe una actividad que se considera importante en el logro de la meta específica a la cual se corresponde. Una práctica es un subproceso dentro de un área de proceso que contribuye al logro de un objetivo del área de proceso (Curtis, Hefley et al. 2009). Una práctica describe una actividad que se considera importante en el logro de la meta específica a la cual se corresponde. Se describen a continuación los cinco niveles de madurez de People CMM. 3.1 Nivel 1 Inicial Las organizaciones en el nivel Inicial de madurez usualmente tienen dificultades para retener a los individuos talentosos. Estas organizaciones están pobremente preparadas para responder a la escasez de talentos, excepto con slogans y exhortaciones. A pesar de la importancia del talento, las prácticas de recursos humanos en este tipo de organizaciones son a menudo inconsistentes. En algunas áreas la organización no tiene prácticas de recursos humanos definidas, y en otras áreas no tienen un individuo responsable entrenado para ejecutar las prácticas que existan. El nivel Inicial no tiene áreas de proceso asociadas. Si bien las prácticas de gestión de las capacidades de la fuerza laboral llevadas a cabo en organizaciones con este nivel de madurez tienden a ser inconsistentes, prácticamente todas esas organizaciones ejecutan los procesos que se describen en el nivel Nivel 2 Administrado Las áreas de proceso del nivel Administrado se centran en el establecimiento de un fundamento de prácticas básicas de recursos humanos que pueden ser continuamente mejoradas para desarrollar las capacidades de la fuerza laboral. Este fundamento de prácticas 25

26 se construye inicialmente dentro de las unidades de negocio para inculcar una disciplina para la gestión de las personas y para proveer un ambiente de trabajo propicio y con recursos de trabajo adecuados. En la Tabla 3.2 se muestran las áreas de proceso de este nivel de madurez y sus prácticas: Áreas de Proceso Prácticas Contratación 18 Comunicación y Coordinación 11 Ambiente de Trabajo 7 Gestión del Desempeño 14 Entrenamiento y Desarrollo 8 Compensación 11 Tabla 3.2 Áreas de Proceso y Prácticas PCMM Nivel Nivel 3 Definido Una vez que las prácticas básicas de la fuerza laboral han sido establecidas en las unidades (Nivel 2), el próximo paso es que la organización desarrolle una infraestructura que permita atar la capacidad de la fuerza laboral con los objetivos de negocio estratégicos. El objetivo primario del Nivel Definido es ayudar a la organización a ganar ventaja competitiva mediante el desarrollo de competencias variadas que se deben combinar para poder cumplir con las actividades de negocio. Las competencias de la fuerza laboral representan los pilares que soportan los planes de negocios estratégicos, cuya ausencia puede significar un riesgo severo en cuanto a su cumplimiento. Se entiende como competencia, una característica subyacente de un individuo que es causalmente relacionada al desempeño efectivo o superior, de acuerdo a un criterio medible y objetivo en un trabajo o situación (Curtis, Hefley et al. 2009). Las prácticas de nivel 3 son facilitadores críticos de la estrategia de negocio que permitirán atar las competencias de la fuerza laboral con los objetivos de negocio actuales y futuros. El nivel de madurez Definido tiene asociadas las siete áreas de proceso que se muestran en la Tabla 3.3 con la cantidad de prácticas asociadas a cada una: 26

27 Áreas de Proceso Prácticas Análisis de Competencias 8 Planificación de Personal 11 Desarrollo de Competencias 8 Desarrollo de Carrera 8 Prácticas Basadas en Competencias 14 Desarrollo de Grupos de Trabajo 15 Cultura de Participción 12 Tabla 3.3 Áreas de Proceso y Prácticas PCMM Nivel Nivel 4 Predecible La organización entiende y controla el desempeño cuantitativamente dado que los miembros de cada comunidad de competencias desarrollan prácticas basadas en competencias similares, la organización puede cuantificar la capacidad de estos procesos y compararlos con resultados pasados y tomar acciones si es necesario. Esto puede servir para planificar el desempeño futuro y gestionar su trabajo. A su vez, se comienzan a explotar los resultados de los procesos basados en competencias. La organización integra y entreteje los procesos basados en competencias de diferentes competencias de grupos de trabajo en procesos multidisciplinarios para mejorar la eficiencia con la que manejan las dependencias de trabajo. El nivel de madurez Predecible tiene asociadas las seis áreas de proceso que se muestran en la Tabla 3.4 con la cantidad de prácticas asociadas a cada una: Áreas de Proceso Prácticas Integración de Competencias 12 Grupos de Trabajo Autónomos 12 Activos Basados en Competencias 12 Gestión Cuantitativa del Desempeño 9 Gestión de la Capacidad Organizacional 11 Mentoring 10 Tabla 3.4 Áreas de Proceso y Prácticas PCMM Nivel 4 27

28 3.5 Nivel 5 - Optimizado El foco de este nivel se dirige hacia mejorar continuamente la capacidad los individuos. Se inician programas para que las personas puedan mejorar su trabajo. Las personas tienen autonomía como para realizar cambios en los procesos personales que puedan mejorar su desempeño. Sus lecciones aprendidas pueden ser compartidas a la organización de forma que se alimenten las prácticas basadas en competencias. A su vez, se comienzan a mejora la integración de los procesos personales utilizados por los miembros de los grupos de trabajo. La organización utiliza los resultados de la gestión cuantitativa del desempeño para asegurarse que el desempeño en todos los niveles de la organización se alinea a los objetivos de negocio como también para continuamente investigar prácticas innovadoras o tecnologías para ayudar a mejorar la capacidad y motivación de la fuerza laboral. El nivel de madurez Optimizado tiene asociadas las tres áreas de proceso que se muestran en la Tabla 3.5 junto con la cantidad de prácticas asociadas a cada una: Áreas de Proceso Prácticas Mejora Contínua de la Capacidad 15 Alineamiento Organizacional de desempeño 6 Innovación Contínua de la fuerza laboral 13 Tabla 3.5 Áreas de Proceso y Prácticas PCMM Nivel Representaciones del People CMM De acuerdo a (Curtis, Hefley et al. 2003) el People CMM asume que las prácticas respecto a la fuerza laboral pueden ser mejoradas utilizando una representación escalonada del modelo. Este término proviene del Capability Maturity Model Integration (CMMI). En este modelo existen dos representaciones, una es la denominada continua, la cual permite que una organización mejore diferentes procesos en diferentes niveles, por ejemplo, implementar el área de Planificación de Proyecto, que si bien es un área de proceso propia de nivel 2 de CMMI, es posible enfocar su implementación en un nivel 3 e implementar otra área como ser Verificación, área de proceso propia de nivel 3, con un enfoque de nivel 2 (Chrissis, Konrad et al. 2006). 28

29 La otra representación es la escalonada, la cual ofrece una forma estructurada de implementación de las áreas de proceso, es decir un nivel a la vez, primero comenzar con las áreas de proceso de nivel 2 y luego continuar con las de nivel 3 (Chrissis, Konrad et al. 2006). Si bien el People CMM no describe diferentes representaciones, asume que la implementación debe ser de forma estructurada. Cada nivel sucesivo del People CMM produce una transformación única de la cultura de la organización, brindándole buenas practicas para atraer, desarrollar, organizar, motivar y retener su fuerza laboral. Por lo tanto es con esta representación con la que se obtienen los mejores beneficios. Según (Curtis, Hefley et al. 2003), las organizaciones que aplican un nivel 2 de People CMM reportan mejoras en la moral de la fuerza laboral y reducción en la rotación voluntaria, dado que, el mejor predictor de este factor es la relación de los empleados con su supervisor. Cada área de proceso involucra prácticas de implementación, propias de cada área de proceso y prácticas de institucionalización Prácticas de Institucionalización e implementación del People CMM El término institucionalización sugiere la construcción y posterior soporte de una cultura organizacional que apoye el desempeño de las prácticas que ejecuta la fuerza laboral. Las prácticas de implementación están agrupadas dentro de la categoría Prácticas Realizadas Practices Performed. Estas prácticas realizadas en cada área de proceso describen aquellas que deberían ser típicamente implementadas para alcanzar los objetivos de cada área. Este tipo de prácticas aparecen con mucha frecuencia dado que describen la implementación real de cada área de proceso. Las prácticas de institucionalización ayudan a que la implementación del área de proceso sea parte de la cultura, efectiva, repetible y que persista en el (Curtis, Hefley et al. 2009). Tal es el ejemplo de prácticas como Compromiso para Ejecutar Commitment to perform. Las prácticas de institucionalización se encuentran a lo largo de todas las áreas de proceso de todos los niveles. Por ejemplo la práctica de institucionalización Compromiso para Ejecutar se encuentran en las áreas de proceso de Compensación como en Formación y Desarrollo entre otras. 29

30 A continuación se explican cada una de las prácticas de institucionalización: Compromiso para Ejecutar: estas prácticas describen acciones que la organización debe realizar para asegurar que las actividades que constituyen un área de proceso son establecidas y que permanecerán en el tiempo. En general implica la definición de políticas organizacionales, apoyo de la gerencia ejecutiva y la definición de roles a nivel de la organización para poder apoyar las prácticas que contribuyen a desarrollar las capacidades de la fuerza laboral. Habilidad para Ejecutar: estas prácticas describen las precondiciones que deben existir en la unidad u organización para implementar las prácticas competentemente. En general involucra que la organización sea capaz de proveer los recursos, estructuras organizacionales, y preparación para poder ejecutar las prácticas del área de proceso. Medición y Análisis: estas prácticas describen mediciones de las prácticas y analizan estas mediciones. En general incluye ejemplos de mediciones que pueden ser recolectadas para determinar el estado y efectividad con que las prácticas han sido implementadas. Verificar la Implementación: estas prácticas definen los pasos para asegurar que las actividades se realicen de acuerdo a las políticas y procedimientos establecidos. En general estas prácticas acompasan objetivos de revisión y auditorías realizadas por la gerencia ejecutiva u otros responsables. 30

31 4 Trabajos Relacionados Como parte de este trabajo se ha realizado una revisión de la literatura en cuanto a los diferentes factores de éxito para la implementación de mejoras de proceso de software, en su mayoría adoptando el modelo CMMI como también las barreras que impiden el éxito de la institucionalización de la mejora. A lo largo de la revisión se ha identificado que existen dos ángulos desde donde investigar qué permite y qué impide que una organización pueda implementar exitosamente un programa de mejora de procesos. El primer enfoque que debe ser analizado es cómo se percibe la mejora por el individuo que debe ejecutarla o implementarla. El segundo enfoque trata sobre cómo la organización dueña de esta mejora se prepara para que pueda ser institucionalizada. Este último enfoque da a lugar a mencionar aspectos de cultura organizacional y gestión del cambio, los cuales impactan directamente en el éxito de actividades de mejora de procesos. En las siguientes secciones se mencionarán las distintas investigaciones y estudios resultantes de la revisión. 4.1 Trabajos basados en la visión personal del individuo involucrado en la mejora de proceso de software De acuerdo a (Umarji and Seaman 2005), en organizaciones en donde se realizan mejoras de procesos de software existen muchos problemas de aceptación porque implica factores como aprendizaje de nuevas tecnologías, cambios en la forma de trabajar y carga de trabajo adicional. Por otro lado también, en esta clase de iniciativas, se necesita recolectar datos de proyectos, recursos y productos entregables y en muchas ocasiones las personas no se sienten cómodas brindándolos. En trabajos de investigación de literatura psicológica social (Ajzen 1991), (Davis 1989) se han investigado problemas que aparecen ante la introducción de innovaciones tecnológicas o de sistemas de información y de acuerdo a (Umarji and Seaman 2005), introducir un sistema de información es análogo a implementar una mejora de proceso de software dado que las razones para embarcarse en estas iniciativas son similares. Ello involucra presupuesto, consideraciones de tiempo, presiones del mercado y estándares de la industria que 31

32 evolucionan. A su vez ambas iniciativas involucran recursos y causan cambio organizacional. La diferencia entre las iniciativas es que las mejoras de proceso de software tienen un mayor impacto en el trabajo diario de las personas y los beneficios son más tangibles comparados con el uso de una innovación de tecnología de información. (Umarji and Seaman 2005) comentan que la mejora de procesos involucra la utilización de nuevas herramientas y técnicas, las cuales encuentran resistencia dado que los cronogramas no permiten trabajo adicional como ser revisiones de código o reuniones extras. A su vez los empleados tienden a asumir que las iniciativas serán indicadores de su desempeño. De cualquier forma es necesario estudiar qué se puede hacer para reducir esta resistencia y sostener procesos de mejora en las organizaciones. Otros autores estudiaron el modelo Technology Acceptance Model (TAM) (Davis 1989) para poder tratar los diferentes problemas de aceptación en organizaciones de software. Este modelo se basa en la psicología social y predica que los conceptos de Facilidad de Uso y Utilidad pueden predecir la utilización de un sistema. La facilidad de uso se entiende como el nivel en el que una persona cree que utilizando un sistema en particular no consumirá esfuerzo (Davis 1989). El concepto de utilidad se define como el nivel en que una persona cree que utilizando un sistema en particular mejoraría su rendimiento (Davis 1989). Otro modelo estudiado es el de Theory of Planned Behavior (TPB) (Moore and Benbasat 1991). Este es un modelo más general que ha sido aplicado a muchos dominios incluido el de sistemas de información, para predecir el comportamiento real basado en el comportamiento intencional. Para su estudio (Umarji and Seaman 2005), los autores han considerado algunas categorías de problemas que afectan la aceptación de la mejora de procesos en organizaciones en cuanto a la definición de un modelo de métricas para medir la aceptación de un programa de métricas. Estas son organizacionales, personales, factores relacionados a la mejora de procesos y factores provenientes del dominio de psicología social y organizacional. Entre otros factores se pueden destacar: Visibilidad: el concepto se enfoca en la visibilidad en cuanto a los objetivos de la organización. Es posible que una evaluación de la visibilidad de los objetivos durante la fase inicial de las iniciativas de mejora de procesos de software permita tener una noción en cuanto a su aceptación. (Umarji and Emurian 2005) enuncian las dudas y aprensiones de los involucrados deben ser atendidas para poderlos convencer de participar en la iniciativa de la generación de un programa de métricas. Esto puede ser análogo a cualquier mejora de proceso. 32

33 Transparencia: la transparencia facilita el entendimiento y trazabilidad y en consecuencia, la voluntad de adaptarse. Los autores sugieren que para poder predecir la aceptación de una mejora de proceso, es importante evaluar cómo conciben los desarrolladores la iniciativa. Estructura de recompensa/incentivos: las estructuras de recompensas son parte de las políticas de la organización y si son definidas y comunicadas efectivamente, pueden ayudar a motivar a la adopción de metodologías de procesos de software en general. Importancia del Trabajo: (Umarji and Emurian 2005) en su trabajo destacan este factor asociado a la utilidad. Si los desarrolladores creen que el proyecto en el que están trabajando es importante en términos de impacto en la organización y de equipo, su idea de utilidad se incrementará. Imagen y visibilidad: este constructo refiere al estado social de una persona. En las organizaciones este factor puede percibirse que afecte la carrera profesional de la persona. En cuanto a problemas personales, los autores describen: Miedo a consecuencias adversas: si las actividades de mejora de procesos no son incluidas en la planificación, los involucrados en las mismas podrían temer que insumir tiempo en estas actividades podría afectar su desempeño laboral. Por otro lado, estos podrían dudar a la hora de reportar ineficiencias de sus compañeros o cualquier otro factor que genere conflictos de interés en el equipo y sus supervisores. A menos que esta aprensión sea tratada al principio de la implementación, podrían afectar la asimilación posterior. Comunicación: la organización debe tener buenos canales de de comunicación definidos, de forma que todas las políticas puedan ser comunicadas efectiva y claramente. A su vez, es importante también que los involucrados en estas actividades de mejora tengan buenas habilidades interpersonales y de comunicación. Por lo tanto la comunicación es un buen determinante en cuanto a si una actividad de mejora de procesos será efectiva y exitosa. Auto Eficacia (self-efficacy): se relaciona con la evaluación de la competencia de un individuo para realizar una tarea específica en un dominio dado basándose en su experiencia, conocimiento, opiniones de colegas y condiciones psicológicas. Grado de Control: el control significa al grado en que un desarrollador puede realizar sugerencias en cuanto a cambios y sentirse involucrado en actividades de mejora de procesos 33

34 de software. El control que un desarrollador tiene en la planificación e implementación de la mejora de procesos puede impactar su auto eficacia y también la adopción. En cuanto a problemas relacionados con la mejora de procesos de software, se pueden observar: Cantidad de aprendizaje obtenido: una cantidad razonable de entrenamiento debería ser provista para que la fase de migración hacia nuevas tecnologías y procesos sea más fácil para los que deban realizar las actividades. Compatibilidad de prácticas de trabajo: las actividades de mejora de procesos de software deben ser compatibles con las actividades ya existentes. Defensores de la mejora de procesos: el marketing de la iniciativa en la compañía es una buena estrategia para reducir la resistencia de los que deben realizar las actividades. Los defensores de éstas (champions en inglés), aumentan la probabilidad de comprar estas iniciativas al nivel de los que ejecutan las tareas. Por último (Umarji and Seaman 2005) toman en cuenta algunos factores de la psicología social: Utilidad Percibida: el constructo Utilidad derivado de TAM puede ser visto desde dos perspectivas, desde el punto de vista organizacional y personal. El organizacional es la percepción del desarrollador sobre cómo su participación con la mejora de procesos de software será beneficiosa para la organización (y directamente al desarrollador). La perspectiva personal es la percepción del desarrollador de cómo la realización de actividades de mejora de procesos de software podrá mejorar su satisfacción laborar y desarrollo de carrera. Actitud: se trata del nivel en que una persona tiene una evaluación favorable o desfavorable del comportamiento en cuestión (Ajzen 1991). Control de comportamiento percibido: de acuerdo a PCB se trata de la percepción de una persona de la facilidad o dificultad de realizar el comportamiento (Ajzen 1991). PCB incluye factores internos y externos. Los factores externos son aquellas cosas fuera de la persona que puede afectar el comportamiento, por lo tanto, se pueden incluir los recursos del usuario como ser documentación, disponibilidad de ayuda, personal confiable y experimentado, estabilidad 34

35 financiera adecuada. Los factores internos refieren a la facilidad o dificultad persona de realizar un comportamiento, basado en sus anteriores experiencias, habilidades obtenidas a través del aprendizaje e inteligencia (Umarji and Seaman 2005). Norma Subjetiva: refiere a la presión social percibida para realizar o no un comportamiento (Ajzen 1991). Este factor juega un rol importante en la mejora de procesos de software, dado que si un desarrollador siente que determinada mejora no tiene sentido, éste puede influenciar la gente a su alrededor y esta actitud se esparce en el grupo. Facilidad de Uso: tal como se describió anteriormente, la facilidad de uso se entiende como el nivel en el que una persona cree que utilizando un sistema en particular no consumirá esfuerzo (Davis 1989). Este factor refiere al nivel de complejidad de la mejora de proceso de software y facilidad con la que los involucrados pueden adaptarse a los cambios en las prácticas de mejora. Intención: de acuerdo a (Umarji and Emurian 2005) este factor captura los aspectos motivacionales que influencian el comportamiento. Son los indicadores sobre el nivel en que la gente realizar algo. En un estudio realizado por (Riemenschneider and Hardgrave 2002) se plantea la siguiente pregunta de investigación: Cuáles son los determinantes de las intenciones individuales de los desarrollador de software para usar metodologías dentro de las organizaciones que intentan implementarlas? Para la realización de este estudio (Riemenschneider and Hardgrave 2002), examinan 5 modelos de aceptación de herramientas de tecnologías de información por individuos. Estas metodologías incluyen TAM, TAM2, Características percibidas de la Innovación (PCI), TPB y el Modelo de Utilización de Computadores Personales (MPCU). En este estudio los autores aclaran que si bien el uso de una tecnología es diferente al uso de una metodología, existen ciertos puntos en común que sugieren que algunos determinantes de adopción de una tecnología pueden ser aplicables al dominio de metodologías. Algunos de ellos pueden ser: el grado de adopción que requiere la alta gerencia sobre el objetivo de la innovación suele ser mayor en cuanto a metodologías que en cuanto a herramientas. la magnitud del cambio de comportamiento implicado en la adopción de una metodología es mayor que en la de una herramienta. 35

36 el mayor énfasis en el uso de equipos de proyecto para organizar el trabajo de desarrollo de software, incrementa la influencia de los compañeros comparado con el uso individual de herramientas. Los modelos contemplados en este estudio incluyen constructos que reflejan las influencias externas de la organización y de los grupos en la intención individual de usar las metodologías, como también preocupaciones individuales de adopción. Los determinantes de intención que se contemplan en este estudio son: utilidad, voluntariedad, compatibilidad y norma subjetiva. Los resultados del estudio indican que la utilidad de una metodología y compatibilidad con los procesos existentes influencian fuertemente su aceptación. A su vez y contrariamente a lo que se puede suponer, la aceptación de la metodología no se asegura solamente porque es requerido por la organización. TAM2 es una extensión del modelo TAM diseñada para abarca situaciones de voluntariedad y obligación de uso incluyendo dos constructos adicionales: Norma Subjetiva (definida anteriormente) y Voluntariedad que se define como el grado en que las personas que acogerán la decisión de la adopción de forma voluntaria (Davis and Venkatesh 2000). PCI es un término llamado por (Moore and Benbasat 1991) respecto a la adopción de computadores personales. Aquí se presentan siete constructos: Ventaja Relativa: grado en el que una innovación es percibida mejor que su precursora. Complejidad: grado en el que una innovación es percibida difícil de usar. Compatibilidad: grado en el que una innovación es percibida como consistente con los valores existentes, necesidades, y experiencias pasadas de futuros usuarios de la misma. Capacidad de demostrar Resultados: grado en el que una innovación es percibida como dispuesta a presentar ventajas tangibles. Imagen: grado en el que el uso de una innovación es percibida para mejorar la imagen de una persona o el status social. Visibilidad: grado en el que los resultados de una innovación es observable por otros. Voluntariedad (ya definida anteriormente) MPCU incluye factores sociales, los cuales refieren a la internalización individual de la cultura subjetiva de los grupos y acuerdos interpersonales que el individuo ha hecho con 36

37 otros. MPCU maneja los siguientes factores (Thompson Ronald L., Higgins Christopher A. et al. 1991): Afectación: refiere a las reacciones emocionales positivas o negativas que un individuo asocia con un acto particular. Adecuado para el Trabajo: misma definición que Utilidad Percibida en TAM. Consecuencias de Carrera: Dimensión de consecuencias de uso a largo plazo. Condiciones que facilitan: son factores en el ambiente que facilitan un acto. TAM y TPB han sido descritos anteriormente. Los cinco modelos tienen constructores únicos y comunes. Todos tienen un constructo equivalente a Utilidad Percibida. Se explica en la Tabla 4.1 las diferencias y similitudes encontradas (Riemenschneider and Hardgrave 2002). Tabla 4.1 Modelos Teóricos (Riemenschneider and Hardgrave 2002) Los resultados generales de este estudio demuestran que la aceptación de una metodología por un desarrollador va más allá de una política impuesta por la alta gerencia, siendo o de la percepción de que cierta tarea debe ser realizada obligatoriamente, esto un común error en las 37

38 organizaciones. Si la metodología no es percibida como útil entre los desarrolladores su éxito está puesto en duda. Entre los factores de presiones externas la medida de rendimiento y estructura de recompensa son los que más influyen. La metodología no podrá ser sostenida a lo largo del tiempo si los desarrolladores no perciben que la misma resulta en una mejor productividad y mejora el desempeño de los mismos. Por otro lado, si la metodología se aleja de la forma actual en que los desarrolladores ejecutan su trabajo, habrá menos posibilidad de adopción por parte de ellos (Riemenschneider and Hardgrave 2002). En un artículo (Abrahamsson 2001) estudia el desarrollo del compromiso en cuanto al éxito de las mejoras de proceso de software, el cual juega un papel importante en el mismo. Una definición común para compromiso utilizada en la literatura de mejora de procesos de software es dada por el CMMI es un pacto que es libremente asumido, visible y se espera que sea conservado por todas las partes (Olson, Over et al. 1994), sin embargo este tipo de pacto explícito es solo una parte del concepto de compromiso, dado que también es la relación entre una persona y una entidad. La falta de compromiso de la gerencia siempre ha sido discutida como una causa de la falla para implementar y mantener mejoras de proceso de software en una organización, como también la falta de compromiso del usuario del proceso (tester, desarrollador). En este artículo (Abrahamsson 2001) desarrolla diferentes clasificaciones del constructo compromiso para analizar este factor en profundidad. 4.2 Trabajos basados en la visión de la organización dueña de la mejora de proceso de software Existen investigaciones que han sido realizadas para poder explorar la importancia relativa de problemas organizacionales en la mejora de procesos de software (Dyba 2000), (Dyba 2003), (Dyba 2005). En sus estudios sugiere que la clave para el aprendizaje exitoso es una dialéctica continua y simultanea entre el conocimiento que la organización ha establecido a lo largo del tiempo y el conocimiento de los miembros de la organización y sus respectivos contextos. A su vez comenta que el éxito de una mejora de procesos de software depende críticamente en 6 factores organizacionales: orientación del negocio, liderazgo involucrado, participación del empleado, preocupación por la medición, explotación del conocimiento existente y la exploración de nuevo conocimiento. 38

39 Lo que estos factores sugieren es que en vez de tratar de imitar procedimientos técnicos, las organizaciones de software deberían enfocar sus esfuerzos de mejora de procesos en crear una cultura organizacional en donde estos procedimientos puedan prosperar. Por otro lado también identificó para cada uno de estos factores, indicadores presentados en la Tabla 4.2. Tabla 4.2 Factores Claves para el éxito de las mejoras de proceso de software De forma similar (Goldenson and Herbsleb 1995) han estudiado similares factores que permiten una implementación exitosa de mejora de procesos de software. Estos son: monitoreo de las mejoras por parte de la alta gerencia, responsabilidades compensadas de la 39

40 mejora de procesos de software, objetivos de la mejora explicados, miembros técnicos involucrados en la mejora, respeto por el personal dedicado a la mejora de procesos de software, tiempo del personal/recursos dedicados al progreso de la mejora. Por otro lado también identifica barreras que impiden la implementación exitosa, como ser: perspectivas desalentadoras de las mejoras de proceso de software, las mejoras de proceso de software entorpecen el camino del trabajo real, demasiado control inhibe las mejoras, existencia de políticas organizacionales, recomendaciones de evaluaciones ambiguas, necesidad de una guía acerca de cómo mejorar, necesidad de mentoring y asistencia, desánimo y cinismo por experiencias anteriores. Otra investigación realizada (Niazi, David et al. 2007) observa que en organizaciones con alto nivel de madurez de CMMI están más preparadas para la implementación de mejoras de procesos de software que las de bajo nivel de madurez. Sin embargo en las organizaciones con alto nivel de madurez demuestra que aún éstas deben trabajar en aspectos como presión de tiempo y tiempos de equipo y recurso. En las organizaciones de baja madurez, los factores conciencia de mejora de procesos de software, equipo experimentado, falta de soporte entrenamiento y mentoring y revisiones son aspectos que fallan a la hora de la implementación de estas mejoras. En investigaciones anteriores (Niazi, Wilson et al. 2006) (Niazi, David et al. 2006b) también se mencionan estos mismos factores. En su investigación (Niazi, David et al. 2003), exploran empíricamente los puntos de vista y experiencias de personas involucradas en la mejora de procesos de software y basándose en esos resultados desarrollan un modelo de forma de poder guiar a estos involucrados en una implementación exitosa de programas de mejora. Estos investigadores además de basarse en la literatura del tema, han realizado un cuestionario con factores críticos de éxito a 3 categorías de encuestados: Diseñadores/testers/programadores/analistas, denominados desarrolladores. Líderes de equipos, gerentes de proyecto, denominados Gerentes Alta gerencia/directores, denominados Gerentes de Alto mando En la Tabla 4.3 se muestra la frecuencia en que aparecen los factores críticos de éxito tomados de literatura y de las encuestas. El % muestra la proporción encontrada en literatura y en las encuestas realizadas. 40

41 Tabla 4.3 Factores Críticos de Éxito de la literatura estudiada y estudio empírico De acuerdo a estos resultados los factores más citados en la literatura es compromiso de la alta gerencia, por ejemplo con un 66%. Esto sugiere que en la opinión de los involucrados en las actividades de mejora, el apoyo de la gerencia puede jugar un rol vital en la implementación de programas de mejora de procesos de software. Otros factores citados con frecuencia en la literatura son la participación del equipo (51%), y el entrenamiento y mentoring (49%). Otros factores que resaltan son tiempo del equipo y recursos, creación de equipos de procesos. Algunos de estos factores coinciden con el estudio realizado por (Niazi, David et al. 2007). 41

42 En cuanto a los factores que surgen de las entrevistas el entrenamiento y el compromiso de la alta gerencia (71% y 65% respectivamente) son los más sobresalientes. Se destacan dos nuevos factores críticos de éxito, conciencia y metodología formal, que han sido identificados en el estudio empírico. Otros factores con frecuencia citados son recursos, participación del equipo y equipo experimentado. Estos factores también han sido detectados en el estudio de (Niazi, David et al. 2007). Por otro lado (Niazi, David et al. 2003), tratan de identificar las barreras críticas para entender la naturaleza de los problemas que subyacen en la implementación de mejoras de proceso de software. Las barreras se identifican en la Tabla 4.4. Tabla 4.4 Barreras Críticas encontradas en literatura y entrevistas Los resultados muestran que la mayoría de los involucrados en las actividades de mejora consideran que la falta de recursos es la principal barrera crítica para la implementación de actividades de mejora de procesos de software. A su vez los resultados también sugieren que la presión de tiempo y la inexperiencia del equipo pueden socavar los programas de mejora. Es también un aspecto a destacar que los involucrados en realizar la mejora prefieren evitar las políticas organizacionales durante la implementación de la misma. 42

43 En base a la identificación de los factores críticos de éxito y la barreras (Niazi, David et al. 2003) definen un modelo de implementación de mejoras de procesos de software. Este modelo implica: Dimensión de Fase de Implementación de mejora de procesos de software Dimensión de factores críticos de éxito y barreras críticas en la implementación de mejoras de proceso de software. Dimensión de Fase de Implementación de mejora de procesos de software Concientización: es necesario generar concientización de los programas de mejora de procesos de software de forma de poder entender sus beneficios. Los involucrados en estos programas comentan que al ser estas nuevas prácticas en la organización, es muy importante promoverlas y compartir el conocimiento entre los diferentes actores. Se sugiere involucrar a todos los miembros en estos programas de concientización. Aprendizaje: en cuanto al aprendizaje, el entrenar a los involucrados en habilidades de mejora de procesos de software es crítico para el uso eficiente de la misma. Esta fase involucra equipar a los actores involucrados con el conocimiento de las tecnologías más importante que se necesitan para la mejora. Implementación de Pilotos: los involucrados en la mejora recomiendan primero implementarlas a un bajo nivel y ver que tan exitosa resulta en un contexto particular. Es importante también que estos puedan juzgar sus habilidades en el piloto de implementación. Es aquí en donde pueden decidir cuántos recursos, entrenamiento y compromiso se requiere para poder implementar las mejoras de proceso de software en toda la organización. Plan de acción de implementación de mejoras: los involucrados enfatizan la necesidad de un plan y gerenciamiento apropiado. Este plan debería estar basado en los resultados de los pilotos. Implementación en toda la organización: luego de una planificación apropiada y de utilizar las experiencias recogidas del piloto, es posible implementar la mejora en toda la organización o en las unidades/departamentos necesarios. Se sugiere una implementación proyecto a proyecto. Por otro lado el compromiso de la alta gerencia cumple un rol muy importante en esta fase. 43

44 Mantenimiento: luego de la implementación es necesario monitorear y dar soporte continuamente a la mejora. La concientización y el entrenamiento son actividades a contemplar en esta actividad dado que es muy probable que las personas cambien de rol. Por otro lado muchas mejoras no tienen efectos a largo plazo porque las personas vuelven a sus hábitos anteriores de realizar el trabajo. Por lo tanto es importante brindar continuamente retroalimentación, tutorías, motivación y reforzar la importancia de las mejoras para mantenerlos involucrados en estas actividades. Dimensión de factores críticos de éxito y barreras críticas en la implementación de mejoras de proceso de software De acuerdo a (Niazi, David et al. 2003) las personas que implementan mejoras de proceso de software deben tener en cuenta los factores críticas de éxito y las barreras críticas. En su estudio empírico (Niazi, Wilson et al. 2003) (Niazi, Wilson et al. 2004b), han generado cuestionarios específicos que soportan cada factor crítico de éxito y barreras. Este cuestionario considera prácticas a tener en cuenta respecto a los siguientes factores críticos de éxito y barreras: concientización, creación de equipos de acción, personal experimentado, metodología formal, falta de apoyo, compromiso de la alta gerencia, revisiones, participación del personal involucrado, tiempo de personal involucrado y recursos dedicados a la mejora de procesos de software, presión de tiempo, entrenamiento y mentoring, políticas organizacionales, asignación de responsabilidad para la mejora de procesos de software, objetivos de mejora claros y entendidos, alentar a la comunicación y colaboración, facilitación, gestión de las mejoras, esquemas de recompensa. En la misma línea de investigación (Brietzke and Rabelo 2006) investigan barreras que evitan que los factores de los anteriores autores puedan desarrollarse con éxito, siendo estas la falta de adhesión y participación de los involucrados, falta de compromiso en todos los niveles de la organización, falta de habilidades para implementar el cambio cultural y falta de liderazgo y soporte de la alta gerencia. Continuando sus investigaciones Niazi (Niazi and Ali Babar 2007) se plantea preguntas de investigación tales como cuáles son los motivadores respecto a la mejora de procesos de 44

45 software que tienen el mayor valor percibido para los que implementan las mejoras. La respuesta a esta pregunta arroja los siguientes factores categorizados por los roles involucrados (desarrolladores y gerentes): Factores percibidos por desarrolladores: expectativas de carrera, comunicación, costos beneficiosos, automonía (empowerment), líderes de equipo con conocimiento, procesos fácilmente mantenidos, recursos, mejores prácticas compartidas, compromiso top-down, éxito visible, automatización, participación en iniciativas, procesos simples, eliminación de burocracia, retroalimentación, introducción por fases de la mejora, propiedad del proceso, estandarización, entrenamiento. Factores percibidos por los gerentes: satisfacción laboral, líderes de equipo con conocimiento, procesos fácilmente mantenidos, cumplimiento de objetivos, mejores prácticas compartidas, obligatoriedad en cuanto a la mejora de procesos de software, reducción de trabajo administrativo, esquema de recompensas, percepción de las mejoras de proceso de software como instrumento para acceder a mejores empleos, mejora en los puestos jerárquicos de la organización, beneficios justificados. En otra investigación, (Niazi and Ali Babar 2008), se encuentra las siguientes barreras: falta de gestión de proyecto, falta de recursos, inercia, falta de compromiso, falta de conocimiento, falta de conocimiento sobre mejora de procesos de software, falta de soporte, falta de comunicación, falta de una metodología para implementación de mejora de procesos de software, cambio de actitud de personal de gerencia y técnico, falta de entrenamiento, presión del tiempo, experiencias negativas, falta de herramientas, políticas organizacionales, la mejora de proceso de software entorpece el trabajo, trabajo administrativo, rotación. A su vez las confirma en posteriores investigaciones (Niazi 2009), (Niazi, Ali Babar et al. 2010). Una investigación similar (Nasir, Ahmad et al. 2008; Nasir, Ahmad R. et al. 2008b) coinciden con dos barreras también identificadas por (Brietzke and Rabelo 2006), siendo estas falta de adhesión y participación de los involucrados, falta de compromiso en todos los niveles de la organización. En tercer lugar identifican las expectativas no realistas respectos a proyectos de mejora de procesos de software como otra barrera. Estas 3 barreras las clasifican dentro de la categoría Factor Humano. Siguiendo esta misma línea de investigación (Nasir, Ahmad et al. 2008; Nasir, Ahmad R. et al. 2008b) coincide en los mismos factores que (Nizam, Ahmad R. et al. 2008; Nasir, Ahmad R. et al. 2008b), agregando los siguientes: falta de una política de Calidad, evaluación insuficiente e inefectiva de los procesos actuales de software, existencia de equipos para la mejora de procesos de software no enfocados en la orientación y soporte técnico. 45

46 Siguiendo la misma línea (Jalote 2002) menciona como factor relevante para el éxito de las mejoras de procesos de software, tener un tener un grupo dedicado responsable de la iniciativa con algunos miembros de tiempo completo, como también tener un sistema adecuado para la implementación de los procesos. También menciona la importancia del compromiso de la alta gerencia. En su estudio (McGuire and Randall 1998), enfatizan que la mejora de proceso de software involucra áreas claves como ser cambio organizacional, entrenamiento organizacional, alineamiento estratégico, entre otras. En cuanto al cambio organizacional, una estrategia de cambio debería ser utilizada desde el comienzo de la mejora del proceso, de forma de poder anticipar posibles causas de resistencia al cambio. El beneficio del cambio debe ser claro y un sistema de recompensa implementado que reconozca el cambio del esfuerzo individual al esfuerzo de grupo que implementa el cambio. Por otro lado este estudio sugiere que la alta gerencia adopte un estilo de coaching en vez de control a la hora de manejar a los empleados respecto al cambio. Por otro lado el continuo aprendizaje debe estar institucionalizado para que una organización alcance la máxima utilización de las personas y que permanezca competitiva. Los objetivos, valores, creencias y acciones de la organización, de la gerencia, de los equipos y unidades de trabajo, deben estar alineados con el esfuerzo de mejora. Otra investigación que estudia un marco de evaluación para verificar si están preparados para sobrellevar un programa de mejoras (Wilson, Hall et al. 2001), toma como modelo el marco de evaluación de (Jeffery and Berry 1993) para un programa de métricas. (Wilson, Hall et al. 2001) han adaptado este marco y preguntas asociadas para que pueda ser utilizado en este estudio. Como conclusión a esta investigación, se arriba a que solo cuatro de esas preguntas resultan ser indicadores significativos entre empresas que han sido exitosas y no exitosas en la implementación de mejora de procesos de software. Estas refieren a: 46

47 Existía compromiso de la alta gerencia? El programa de mejora de procesos de software, estaba conformado por personal respetado? Los procesos iniciales importantes a ser mejorados estaban definidos? Se establecieron las aptitudes para que los usuarios pudieran explicar los eventos y fenómenos asociados al programa? (Montoni and Rocha 2007) en su estudio han identificado propiedades de algunos factores críticos de éxito tomados de la literatura, en la tabla 4.5 se muestran los mismos: Tabla 4.5 Propiedades de factores críticos de éxito Luego del análisis cualitativo y cuantitativo consideran solamente los factores del 1 al 5 por ser los más significativos que influyen en una implementación de mejora de software exitosa. Estos factores son: Factor 1 Ambiente: las variables asociadas a este factor miden si existen condiciones favorables para iniciar y sostener una mejora de procesos de software desde dos puntos de vista: individual y organizacional. 47

48 Factor 2 - Estrategia eficiente de implementación de mejora de procesos de software: esta estrategia asegura que los miembros de la organización son concientes de los beneficios potenciales que pueden alcanzarse con la mejora. Factor 3 Sólida implementación de mejora de procesos de software: las variables miden el nivel de resistencia de la institucionalización de procesos en cuanto a los cambios organizacionales, por ejemplo rotación del personal, dificultades inherentes a la implementación de las mejoras. Factor 4 Compromiso: el compromiso de la alta gerencia en cuanto a la mejora de procesos de software, provisión de recursos financieros adecuados, adecuadas competencias y disponibilidad del personal que ejecuta el proceso de cambio. Factor 5 Motivación y aceptación de la mejora de proceso de software: indica que el equipo de mejoras facilita la aceptación de los miembros de la organización. Desde la perspectiva del cambio organizacional relacionado con la mejora de procesos de software (Stelzer and Mellis 1999) han definido factores basándose en los modelos CMM y estándares ISO Los factores que han investigado son: Agentes de cambio y líderes de opinión: los agentes de cambio inician y dan apoyo a los proyectos de mejora a nivel corporativo, los líderes de opinión lo hacen a nivel local. Alentar a la comunicación y colaboración: nivel al cual los esfuerzos de comunicación preceden y acompañan a los programas de mejora (comunicación), y nivel en el que el personal de diferentes equipos y departamentos cooperan (colaboración). Compromiso y Apoyo de la gerencia Manejo del proyecto de mejora: nivel en el que es controlado y planificado Mejorar el entendimiento provisto: nivel adquirido y transferido a la organización del conocimiento de los actuales procesos de software y actividades de negocio interrelacionadas. Establecer objetivos realistas y relevantes: nivel en el que los esfuerzos de mejora contribuyen al éxito de la organización (relevantes) y en el que los objetivos son alcanzables en un futuro cercano (realista). 48

49 Procesos de cambio estabilizados: nivel en el que los procesos de software son continuamente soportados, mantenidos y mejorados localmente. Participación del equipo Adaptación de la iniciativa de la mejora: nivel en el que los esfuerzos de mejora son adaptados a las fortalezas y debilidades de los diferentes equipos y departamentos. Descongelar la organización (Alvesson and Sveningsson 2008): Nivel en el que la resistencia interna se sobrelleva en una organización. Para realizar el estudio, se tomaron diferentes reportes realizados por diferentes empresas que han implementado esfuerzos de mejora de procesos de software y consecuentemente se revisó la cantidad de veces que los factores antes descritos se mencionan en los reportes. Los factores que más se mencionan son (tomando solo los 3 más mencionados) son: soporte y compromiso de la gerencia, participación del equipo y mejorar el entendimiento provisto. (Baddoo and Hall 2002a) realizaron un estudio sobre los factores motivadores para la mejora de procesos software en el que participaron alrededor de 200 profesionales de software de 13 empresas del Reino Unido, considerando los puntos de vista de los desarrolladores, administradores de proyectos y altos directivos de esas organizaciones. Del análisis de los datos recogidos, los autores sugieren que la aplicación de mejora de procesos de software puede ser mejorada por la gestión adecuada de las motivaciones comunes entre los distintos grupos profesionales (desarrolladores, gerentes de proyecto y alta gerencia). En la tabla 4.6 se describen los factores motivadores de los diferentes grupos involucrados en el proceso de mejora de procesos de software. 49

50 Tabla 4.6 Motivadores para grupos de involucrados El análisis de este estudio brinda que los factores comunes motivadores encontrados en los diferentes grupos son: Propiedad del proceso (Process ownership): los involucrados en las mejoras pretenden querer responsabilidad por el proceso en el que trabajan. Evidencia (evidence): todos los grupos involucrados desean evidencia del éxito de la mejora de procesos de software. Del análisis de este estudio los autores sugieren que las compañías podrían beneficiarse de la publicidad que realicen respecto a experiencias de esta clase de mejoras al resto de la organización. Recursos (resources): aunque todos los involucrados consideran los recursos como motivadores de las mejoras, existen diferencias sutiles en las expectativas de los diferentes grupos. Estos autores (Baddoo and Hall 2002b) también analizaron los datos recogidos en este estudio con el objetivo de identificar la relación entre factores de motivación que los directivos responsables de mejoras de procesos de software deben considerar en el diseño de estrategias de implementación de las iniciativas de mejora de procesos. 50

51 En otro artículo (Baddoo and Hall 2003) estos mismos autores reportan los resultados de otro estudio exploratorio realizado para obtener información más detallada sobre los factores que los profesionales consideran afectan la mejora de procesos software. En la tabla 4.7 se pueden observar los factores desmotivadotes comunes a todos los grupos (Dev Desarrolladores), (PM Gerentes de Proyecto), (SM Alta Gerencia). Tabla 4.7 Factores desmotivadores comunes Del análisis de su estudio, cerca del 45% de los factores son comunes en más de un grupo. Estos factores comunes pueden ser categorizados en: Relacionados a los recursos Presiones comerciales Restricciones de procesos actuales Problemas de implementación Factores personales (Emam, Goldenson et al. 1998) presentan los resultados de un estudio de los factores que tienen influencia en el éxito de las iniciativas de mejora de procesos software. El estudio, en el que se consideraron organizaciones que llevaron a cabo un proceso de evaluación. El estudio analizó datos extraídos a partir de 138 cuestionarios en función del rol de los 51

52 respondientes en las organizaciones (gerente de proyecto de software, desarrollador senior y gerente del grupo de ingeniería de software). A través de la aplicación de técnicas de análisis estadístico, los autores identificaron factores críticos de éxito que se relacionan con los factores relevantes que influyen en el éxito de las mejoras de proceso de software, estos son: Compromiso: definido como el interés de la alta gerencia en las actividades de mejora de procesos. Rotación de personal: respecto a la alta gerencia, niveles de mandos medios y técnicos. Políticas: premisas que motiven a la mejora de procesos de software. Respeto: personal de la mejora de procesos de software respetado Foco: foco en las actividades de mejora Los mismos autores confirman estos resultados en estudios empíricos posteriores (Emam, Goldenson et al. 2001) En otra investigación (Rainer and Hall 2002), concluyen que existen 4 factores críticos de éxito en implementaciones de mejora de procesos de software, siendo estos las revisiones, estándares y procedimientos, entrenamiento y mentoring, y equipo experimentado, por otro lado encuentran otros 4 factores que le siguen en criticidad y estos son liderazgo interno, inspecciones, apoyo de la alta gerencia y propiedad del proceso interno. Muchos de estos tienen coincidencia con el estudio de (Baddoo and Hall 2002b). Desde otro ángulo (Börjesson and Mathiassen 2008) estudian comportamientos de mandos medios y de la alta gerencia de la empresa Ericsson que no ayudan a poder implementar mejoras de procesos de software exitosas. Estos autores identifican cuatro tipos de actitudes que no permiten la correcta implementación, siendo estas: No se presenta, Contesta tardíamente, Muy bueno, pero no ahora, No dice nada. Estas actitudes las relacionan con el compromiso y esfuerzo que se espera de estos roles. A su vez sugieren formas de poder contrarrestar estas barreras. Siguiendo la línea de factores que se relacionan con la alta gerencia y mandos medios respecto a la exitosa implementación de mejoras de proceso de software, (Dion 1999) señala los siguientes: Compromiso continuo Asignaciones claras y apropiadas de responsabilidad 52

53 Infraestructura apropiada para soportar las mejoras de proceso de software Recursos económicos adecuados Enfoque en las necesidades de los proyectos de software Simplificar el esfuerzo para la mejora de procesos de software Estrategia apropiada de transición que impacta en el cambio organizacional. Planificación y monitoreo del esfuerzo en mejoras de proceso de software Justificación adecuada y continua respecto a programas de mejoras de proceso de software En la literatura existen investigaciones que afirman que se puede lograr una sinergia y mejores resultados en cuanto a la implementación de procesos si estos dos modelos (CMMI y People CMM) son implementados en conjunto y que a su vez realza la habilidad de las organizaciones para mantener estas mejoras a lo largo del tiempo (Wemyss and Svoloy 2007). A su vez también se afirma que la implementación del People CMM combinado con el CMMI alinea las prácticas de las fuerzas de trabajo con las de desarrollo para mejorar el desempeño de los negocios de la organización (mejoras en la entrega de productos y servicios como en cuanto a poder cumplir con el cronograma, esfuerzo y calidad comprometidos) y también lograr mayor satisfacción en los clientes y empleados. En 1998, de forma similar (Raffalovich, McWeeney et al. 1998) discuten sobre las organizaciones que implementan People CMM en conjunto con SW-CMM, modelo precursor del CMMI. En su trabajo sostienen que esta implementación conjunta permite mantener mejor la madurez adquirida que habiendo implementado solamente el modelo de mejora continua. 53

54 5 Categorización de Factores La revisión de la literatura presentada en el capitulo anterior permitió identificar un conjunto de factores que inciden en las iniciativas de mejora de procesos software. Estos factores pueden clasificarse, en primea instancia en dos grandes grupos: factores de éxito y motivadores por un lado, y obstáculos, barrera, de resistencia y desmotivadores por el otro. Los factores de éxito son aquellos elementos organizacionales que facilitan y contribuyen de manera positiva a la implementación de una iniciativa de mejora de procesos software. Por el contrario, aquellos factores que obstaculizan, dificultan o imponen restricciones al desarrollo deseado de una tal iniciativa suelen denominarse barreras o factores de resistencia. En la literatura se mencionan también otras dos clases de factores que influyen en una implementación de mejora de procesos software; estos otros factores se denominan motivadores y desmotivadores. (Robbins 1998) define motivación como la voluntad de ejercer altos niveles de esfuerzo hacia las metas organizacionales, condicionadas por la habilidad del esfuerzo de satisfacer alguna necesidad individual. En base a esta definición, factores motivadores son aquellos que incentivan en las personas esa voluntad de esforzarse para contribuir al logro de las metas organizacionales; esto es, la implementación exitosa de una iniciativa de mejora de procesos software. Por el contrario, aquellos factores que degradan o desalientan esa voluntad se denominan desmotivadores. El recuento de los factores encontrados dio un total de 170, discriminados en 109 factores de éxito y motivadores, y 61 factores de resistencia, barreras y desmotivadores. Un primer análisis de la extensa lista de factores obtenida reveló que, en varios casos, diferentes autores utilizaron frases iguales o similares para nombrar algunos factores. Por otra parte, más de un artículo menciona los mismos factores, ya que fueron considerados en más de un estudio o reportados en más de un artículo. Para hacer más manejable la lista de factores y facilitar su análisis, se procedió a crear grupos o categorías en base a similitudes semánticas en los conceptos subyacentes a cada factor. La asignación de factores a cada categoría se vio facilitada en algunos casos por la definición que se provee en el artículo que lo menciona. 54

55 Este proceso de categorización de factores dio como resultado las siguientes 24 categorías que agrupan factores de éxito, motivadores, barreras, desmotivadores y de resistencia. La Tabla 5.1 presenta la cantidad de veces que los factores incluidos en cada categoría se mencionan en la literatura (considerando sus repeticiones cuando alguno aparece mencionado en más de un artículo), discriminados en factores de éxito y motivadores por un lado, y factores de resistencia, barreras y desmotivadores por el otro. Los mismos se encuentran ordenados de mayor a menor frecuencia de mención. Tabla 5.1 Cantidad de menciones por factor en cada categoría La tabla 5.2, por su parte, presenta la cantidad de factores distintos incluidos en cada categoría, también discriminados en factores de éxito y motivadores por un lado, y factores de resistencia, barreras y desmotivadores por el otro. En este caso, los factores que se mencionan en más de un artículo se consideraron solo una vez en el recuento. 55

56 Tabla 5.2 Cantidad de factores en cada categoría A continuación, en la tabla 5.3 se procede a extraer las cinco categorías más mencionadas en la revisión de la literatura. Tabla 5.3 Cinco categorías de factor más mencionadas en la revisión de literatura A continuación se procede a explicar cada categoría de factores mencionando para cada una los factores de éxito, motivadores, factores de resistencia, barreras, obstáculos y desmotivadores, incluyendo los autores que los mencionan. 56

57 Compromiso de la alta gerencia Esta categoría refiere al compromiso de la alta gerencia a la iniciativa de mejora de procesos software. Factores de éxito, motivadores 1. Monitoreo de las mejoras por parte de la Alta Gerencia (Goldenson and Herbsleb 1995) 2. Compromiso (Emam, Goldenson et al. 1998), (Emam, Goldenson et al. 2001), (Dion 1999), (Stelzer and Mellis 1999), (Jalote, 2002), (Niazi, David et al. 2003), (Niazi, Wilson et al. 2004a), (Niazi, Wilson et al. 2006),(Niazi, David et al. 2007), (Wilson, Hall et al. 2001), (Montoni and Rocha 2007), (Abrahamsson 2001), (Niazi and Ali Babar 2007), (Baddoo and Hall 2002a), (Rainer and Hall 2002),(Rainer and Hall 2003) 3. Orientación al negocio (Dyba 2000), (Dyba 2003), (Dyba 2005) 4. Cumplimiento de Objetivos (Niazi and Ali Babar 2007) Factores de Resistencia, Barreras, Desmotivadores 1. Falta de compromiso de la dirección (Baddoo and Hall 2003), (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a), (Niazi and Ali Babar 2008), (Niazi, Ali Babar et al. 2010), (Niazi, Wilson et al. 2004b), (Niazi, David et al. 2007), (Niazi 2009), (Niazi, Ali Babar et al. 2010) 2. Falta de compromiso en todos los niveles de la organización (Brietzke and Rabelo 2006), (Nasir, Ahmad et al. 2008) 3. Falta de liderazgo y soporte de la alta gerencia (Brietzke and Rabelo 2006), (Nasir, Ahmad, Hazzan, 2008a) 4. Falta de una política de Calidad (Nasir, Ahmad et al. 2008) 5. Evitar políticas organizacionales (Niazi, David et al. 2003) 57

58 Objetivos y Políticas de mejora de procesos de software Esta categoría refiere al establecimiento de objetivos precisos, relevantes y alcanzables para la iniciativa de mejora de procesos software. En cuanto a las políticas, refiere a las decisiones y acciones que, a nivel organizacional, pueden influir en la iniciativa de mejora de procesos software. Factores de éxito, motivadores 1. Establecer objetivos pertinentes y realistas (Stelzer and Mellis 1999) 2. Objetivos de mejora claros y entendidos (Niazi, Wilson et al. 2003) (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b), (Goldenson and Herbsleb 1995),(Emam, Goldenson et al. 2001) 3. Objetivos de mejora de procesos claramente establecidos y bien entendidos (Goldenson and Herbsleb 1995), (Emam, Goldenson et al. 1998), (Emam, Goldenson et al. 2001) 4. Justificación adecuada y continua respecto a programas de mejoras de proceso de software (Dion 1999) 5. Existencia de políticas organizacionales (Goldenson and Herbsleb 1995), (Emam, Goldenson et al. 2001), (Emam, Goldenson et al. 1998), (Niazi and Ali Babar 2008), 6. (Niazi 2009), (Niazi, Ali Babar et al. 2010), (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) Factores de Resistencia, Barreras, Desmotivadores 1. Objetivos Irrelevantes (Baddoo and Hall 2003) 2. Falta de consistencia entre los proyectos de mejora de procesos y los objetivos estratégicos de la organización (Nasir, Ahmad et al. 2008; Nasir, Ahmad R. et al. 2008b) 1. Ausencia de enfoque en las necesidades más urgentes de la organización (Nasir, Ahmad et al. 2008; Nasir, Ahmad R. et al. 2008b) 2. Expectativas no realistas respectos a proyectos de mejora de procesos de software (Nasir, Ahmad et al. 2008; Nasir, Ahmad R. et al. 2008b) 3. Baja prioridad de las mejoras de proceso de software (Baddoo and Hall 2003) 4. Costos beneficiosos (Niazi and Ali Babar 2007) 58

59 Comunicación La categoría Comunicación refiere a establecer mecanismos para el intercambio de información entre los involucrados en la mejora de procesos software, y a la diseminación de esa información a nivel organizacional. Factores de éxito, motivadores 1. Beneficios justificados: habilidad de justificar los beneficios de la mejora de procesos de software a largo plazo (Niazi and Ali Babar 2007) 2. Fomentar la comunicación y la colaboración (Stelzer and Mellis 1999), (Niazi, Wilson et al. 2003),(Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 3. Comunicación sobre MPS (Baddoo and Hall 2002a), (Niazi and Ali Babar 2007), (Umarji and Emurian 2005) 4. Retroalimentación de los gerentes y de los clientes (Baddoo and Hall 2002a), (Niazi and Ali Babar 2007) 5. Capacidad de demostrar Resultados (Riemenschneider and Hardgrave 2002) 6. Justificación adecuada y continua respecto a programas de mejoras de proceso de software (Dion 1999) 7. Transparencia (Umarji and Seaman 2005) Factores de Resistencia, Barreras, Desmotivadores 1. Problemas de comunicación (Baddoo and Hall 2003) 2. Falta de retroalimentación (Baddoo and Hall, 2003) 3. Falta de comunicación (Niazi and Ali Babar 2008), (Niazi 2009), (Niazi, Ali Babar et al. 2010) Personal con Habilidades, Conocimientos y Experiencia La categoría Personal con habilidades, conocimientos y experiencia refiere a que las personas dedicadas a las actividades de mejora posean conocimientos y experiencia en mejora de procesos software, así como habilidades adecuadas para gestionar la iniciativa en su conjunto. 59

60 Factores de éxito, motivadores 1. Equipo experimentado (Rainer and Hall 2002), (Rainer and Hall 2003), (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a), (Niazi, Wilson et al. 2006), (Niazi, Wilson, Zowghi, 2007) 2. Líderes de equipo con conocimientos (Baddoo and Hall 2002a), (Niazi and Ali Babar 2007) 3. Competencias de miembros de la Organización(Montoni and Rocha 2007) 4. Aptitudes de usuarios definidas (Wilson, Hall et al. 2001) 5. Auto-eficacia (Umarji and Emurian 2005) Factores de Resistencia, Barreras, Desmotivadores 1. Equipo sin experiencia (Baddoo and Hall 2003), (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a), (Niazi and Ali Babar 2008), (Niazi 2009), (Niazi, Ali Babar et al. 2010), (Niazi, David et al. 2003) 2. Falta de conocimiento (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a), (Niazi and Ali Babar 2008), (Niazi 2009), (Niazi, Ali Babar et al. 2010) 3. Falta de habilidades de gestión de mejora de procesos de software (Baddoo and Hall 2003) 4. Falta de experiencia y habilidades profesionales (Nasir, Ahmad et al. 2008) Capacitación y Mentoring La categoría Capacitación y Mentoring refiere, por un lado, a la provisión de entrenamiento relativo a mejora de procesos software al personal dedicado a las actividades de mejora y, por el otro, al establecimiento de relaciones de tipo mentor-tutelado para la transferencia de conocimientos y experiencia en mejora de procesos software. Factores de éxito, motivadores 1. Entrenamiento provisto a las personas que implementan mejora de procesos de software (Niazi, David et al. 2007), (Niazi, Wilson et al. 2006), (Niazi, Wilson et al. 2006), (Baddoo and Hall 2002a), (Rainer and Hall 2002), (Niazi and Ali Babar 2007) 2. Mentoring (Niazi, David et al. 2007), (Niazi, Wilson et al. 2006), (Baddoo and Hall 2002a), (Rainer and Hall 2002), (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 60

61 3. Facilitación (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 4. Cantidad de aprendizaje obtenido (Umarji and Emurian 2005) Factores de Resistencia, Barreras, Desmotivadores 1. Falta de capacitación (Niazi and Ali Babar 2008), (Niazi 2009), (Niazi, Ali Babar et al. 2010) 2. Falta de capacitación adecuada (Nasir, Ahmad et al. 2008; Nasir, Ahmad R. et al. 2008b) 3. Necesidad de mentoring y asistencia (Goldenson and Herbsleb 1995), (Emam, Goldenson et al. 2001) 4. Necesidad de una guía acerca de cómo mejorar (Goldenson and Herbsleb 1995), (Emam, Goldenson et al. 2001) Conocimiento adquirido y compartido sobre la implementación de la mejora de procesos de software Esta categoría se basa en que el conocimiento, la experiencia y los artefactos resultantes de la realización de procesos basados en las competencias se conviertan en recursos organizacionales, y que estos sean diseminados y utilizados en la organización. Factores de éxito, motivadores 1. Explotación del conocimiento existente (Dyba 2000), (Dyba 2003), (Dyba 2005) 2. Exploración de nuevo conocimiento (Dyba 2000), (Dyba 2003), (Dyba 2005) 3. Mejores prácticas compartidas entre equipos y departamentos (Niazi and Ali Babar 2007) 4. Foro de mejoras de procesos de software para discusión (Baddoo and Hall 2002a) 5. Mejorar el entendimiento provisto (Montoni and Rocha 2007), (Stelzer and Mellis 1999) Factores de Resistencia, Barreras, Desmotivadores 1. Mejores prácticas no compartidas (Baddoo and Hall 2003) 61

62 Percepción de la mejora de procesos de software Esta categoría refiere a cómo el personal involucrado en la mejora de procesos software percibe las iniciativas, ya sea desde el punto de vista de beneficios, concientización, importancia, utilidad entre otros. Factores de éxito, motivadores 1. Éxito Visible (Niazi and Ali Babar 2007), (Umarji and Emurian 2005), (Baddoo and Hall 2002a) 2. Conciencia de mejora de procesos de software ((Niazi, David et al. 2007), (Niazi, Wilson et al. 2006), (Niazi, Wilson et al. 2003),(Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 3. Importancia del Trabajo (Umarji and Emurian 2005) 4. Utilidad Percibida (Umarji and Emurian 2005) 5. Compatibilidad de prácticas de trabajo (Umarji and Emurian 2005), (Riemenschneider and Hardgrave 2002) 6. Eliminación de burocracia (Niazi and Ali Babar 2007) 7. Reducción de trabajo administrativo (Niazi and Ali Babar 2007) 8. Norma Subjetiva (Umarji and Emurian 2005) 9. Imagen (Riemenschneider and Hardgrave 2002) 10. Adecuación para el Trabajo (Riemenschneider and Hardgrave 2002) 11. MPS hace que los profesionales trabajan de manera estandarizada (Niazi and Ali Babar 2007), (Baddoo and Hall 2002a) 12. Control de comportamiento percibido (Umarji and Emurian 2005) 13. Facilidad de Uso (Umarji and Emurian 2005), (Emam, Goldenson et al. 2001) Factores de Resistencia, Barreras, Desmotivadores 1. Falta de Conciencia de las mejora de procesos de software (Niazi, Wilson et al. 2006), (Niazi, Wilson et al. 2003),(Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b), (Niazi and Ali Babar 2008), (Niazi 2009), (Niazi, Ali Babar et al. 2010) 2. Falta de evidencia de beneficios directos (Baddoo and Hall 2003) 3. Malas experiencias previas en mejora de procesos de software (Baddoo and Hall 2003), (Niazi, Wilson et al. 2003),(Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b), (Niazi and Ali Babar 2008), (Niazi 2009), (Niazi, Ali Babar et al. 2010) 4. Desánimo y cinismo por experiencias anteriores (Goldenson and Herbsleb 1995) 5. Perspectivas desalentadoras de las mejoras de proceso de software (Goldenson and Herbsleb 1995) 62

63 Participación del personal La categoría Participación del personal refiere al grado en que el personal dedicado a la mejora de procesos participa y se involucra en la realización de las actividades de mejora y en la toma de decisiones. Factores de éxito, motivadores 1. Participación del personal técnico en el esfuerzo de mejora de procesos de software (Goldenson and Herbsleb, 1995), (Emam, Goldenson et al. 2001) 2. Participación del personal (Stelzer and Mellis 1999), (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b), (Niazi, David et al. 2007), (Niazi, Wilson et al. 2006), (Dyba 2000), (Dyba 2003), (Dyba 2005), (Niazi and Ali Babar 2007) 3. Grado de Control en que el personal puede realizar sugerencias en cuanto a cambios y sentirse involucrado (Umarji and Emurian 2005) 4. Defensores de la mejora de procesos (Umarji and Emurian 2005) Factores de Resistencia, Barreras, Desmotivadores 1. Imposición de la mejora de procesos de software (Baddoo and Hall 2003) 2. Falta de soporte (Niazi and Ali Babar 2008), (Niazi 2009), (Niazi, Ali Babar et al. 2010), (Niazi, David et al. 2007), (Niazi, Wilson et al. 2006), (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) Falta de adhesión y participación de los involucrados (Brietzke and Rabelo 2006) (Nasir, Ahmad et al. 2008; Nasir, Ahmad R. et al. 2008b) Asignación de recursos El concepto de Recursos refiere a la provisión de los recursos humanos, materiales y financieros necesarios para el desarrollo de las actividades de mejora de procesos. En el CMMI las prácticas de institucionalización aseguran que se provean recursos suficientes y adecuados para las actividades de mejora de proceso de software. Otro ángulo del concepto recurso es el del ambiente en donde se deben desarrollar las mejoras de proceso de software. Este ambiente, al igual que en otro tipo de proyectos, debe ser el ideal para que las personas puedan ejecutar sus actividades de forma que puedan ser cumplidas. 63

64 Factores de éxito, motivadores 1. Tiempo de personal y recursos (Goldenson and Herbsleb 1995), (Emam, Goldenson et al. 2001), (Niazi, David et al. 2007),(Niazi, Wilson et al. 2006), (Niazi, Wilson et al. 2006), (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b), (Baddoo and Hall 2002a), (Niazi and Ali Babar 2007) 2. Infraestructura apropiada para soportar las mejoras de proceso de software (Dion 1999) 3. Ambiente (Montoni and Rocha 2007) 4. Herramientas (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 5. Recursos económicos adecuados (Dion 1999), (Riemenschneider and Hardgrave 2002) Factores de Resistencia, Barreras, desmotivadores 1. Falta de Recursos (Niazi, David et al. 2007), (Niazi, Wilson et al. 2006), (Niazi, David et al. 2003), (Baddoo and Hall 2003), (Niazi and Ali Babar 2008), (Niazi 2009), (Niazi, Ali Babar et al. 2010) 2. Falta de Herramientas (Niazi and Ali Babar 2008), (Niazi 2009), (Niazi, Ali Babar et al. 2010), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 3. Restricciones de Presupuesto (Baddoo and Hall 2003) 4. Carga de trabajo excesiva (Baddoo and Hall 2003) Asignación de tiempo La categoría de Tiempo refiere a la dedicación de suficiente tiempo para las actividades de mejora de procesos software. Factores de éxito, motivadores 1. Tiempo de personal y recursos (Goldenson and Herbsleb 1995), (Emam, Goldenson et al. 2001), (Niazi, David et al. 2007), (Niazi, Wilson et al. 2006), (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b), (Baddoo and Hall 2002a), (Niazi and Ali Babar 2007) 64

65 Factores de Resistencia, Barreras, Desmotivadores 1. Presión de Tiempo (Niazi, David et al. 2003), (Niazi, David et al. 2007), (Niazi, Wilson et al. 2006), (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b), (Niazi and Ali Babar 2008), (Niazi 2009), (Niazi, Ali Babar et al. 2010) Grupo de trabajo dedicado a la mejora de procesos de software Esta categoría refiere a establecer un grupo de trabajo cuyos integrantes estén dedicados específicamente a las actividades de mejora de procesos software. Factores de éxito, motivadores 1. Fuerza de trabajo dedicada a la mejora (Baddoo and Hall 2003), (Niazi and Ali Babar 2008) 2. Grupo dedicado responsable de la iniciativa de mejora con algunos miembros de tiempo completo (Jalote 2002) 3. Crear grupos de acción (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) Factores de Resistencia, Barreras, Desmotivadores Existencia de equipos para la mejora de procesos de software no enfocados en la orientación y soporte técnico (Nasir, Ahmad et al. 2008). Respeto, autoridad y responsabilidad del personal de mejoras de procesos de software Esta categoría hace referencia al prestigio y consideración con que las personas dedicadas a la mejora de procesos software son percibidas en la organización. A su vez refiere a la autoridad y responsabilidad de éstas para realizar las actividades asignadas. Factores de éxito, motivadores 1. Personal de MPS respetado (Wilson, Hall et al. 2001) 65

66 2. Respeto por el personal involucrado en mejoras de proceso de software (Goldenson and Herbsleb 1995), (Emam, Goldenson et al. 2001), (Emam, Goldenson et al. 1998), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 3. Respeto por consultores dedicados a mejoras de proceso de software (Montoni and Rocha 2007) 4. Asignaciones claras y apropiadas de responsabilidad (Dion 1999), (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b). Factores de Resistencia, Barreras, Desmotivadores Ninguno Liderazgo La categoría Liderazgo refiere a la actitud de impulsar de manera constante y sistemática las actividades de mejora de procesos software. Factores de éxito, motivadores 1. Liderazgo involucrado (Dyba 2000), (Dyba 2003), (Dyba 2005) 2. Liderazgo interno (Rainer and Hall 2002) Factores de Resistencia, Barreras, Desmotivadores 1. Falta de liderazgo y soporte de la alta gerencia (Brietzke and Rabelo 2006) Compensación La categoría Compensaciones refiere a recompensar en forma específica a las personas involucradas en las actividades de mejora de procesos. A nivel organizacional, la gestión de recompensas se refiere a la formulación y aplicación de estrategias y políticas con el fin de recompensar a las personas de manera justa, equitativa y coherente de acuerdo con su valor a la organización. 66

67 Factores de éxito, motivadores 1. Responsabilidades compensadas de la mejora de procesos de software (Goldenson and Herbsleb 1995),(Goldenson et al. 2001) 2. Esquema de compensación (Niazi and Ali Babar 2007), (Umarji and Emurian 2005), (Niazi, Wilson et al. 2003),(Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) Factores de Resistencia, Barreras, Desmotivadores Ninguno Estrategia de implementación La categoría Estrategia de implementación refiere al establecimiento de un plan para la implementación de la iniciativa de mejora de procesos. Factores de éxito, motivadores 1. Introducción por fases de la mejora (Baddoo and Hall 2002a), (Niazi and Ali Babar 2007) 2. Estrategia eficiente de implementación de mejora de procesos de software (Montoni and Rocha 2007) 3. Adaptación de la iniciativa de mejora (Niazi, Wilson et al. 2003),(Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b), (Stelzer and Mellis 1999) 4. Metodología formal (Niazi, Wilson et al. 2003),(Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 5. Simplificar el esfuerzo para la mejora de procesos de software (Dion 1999), (Niazi and Ali Babar 2007) 6. Secuencia lógica/ orden de implementación (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 7. Procesos fácilmente mantenidos (Baddoo and Hall 2002a), (Niazi and Ali Babar 2007) 8. Tener un sistema adecuado para la implementación de los procesos (Jalote 2002) 9. Enfoque en las necesidades de los proyectos de software (Dion 1999) 10. Sólida implementación de mejora de procesos de software (Montoni and Rocha 2007) 11. Automatización (Niazi and Ali Babar 2007) 67

68 Factores de Resistencia, Barreras, Desmotivadores 1. Enfoque en muchas aéreas de mejora simultáneamente (Nasir, Ahmad et al. 2008; Nasir, Ahmad R. et al. 2008b) 2. Programas de larga escala: La iniciativa de mejora de procesos de software es muy grande para la compañía. (Baddoo and Hall 2003) 3. Evaluación insuficiente e inefectiva de los procesos actuales de software (Nasir, Ahmad et al. 2008) 4. Restricciones de procesos actuales (Baddoo and Hall 2003) 5. Recomendaciones de evaluaciones ambiguas (Goldenson and Herbsleb 1995), (Emam, Goldenson et al. 2001) Estándares y procedimientos La categoría Estándares y procedimientos refiere a generar procedimientos de trabajo formales y procesos documentados. Factores de éxito, motivadores 1. Metodología de implementación de mejoras de proceso de software definida (Niazi, David et al. 2007), (Niazi, Wilson et al. 2006) 2. Estándares y procedimientos (Rainer and Hall 2002), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 3. Procedimientos y procesos (Rainer and Hall 2003), (Montoni and Rocha 2007) 4. Documentación formal (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 5. Los procesos son mantenibles (Baddoo and Hall 2002a), (Niazi and Ali Babar 2007) 6. Procesos iniciales definidos (Wilson, Hall et al. 2001) 7. Estandarización (Niazi and Ali Babar 2007) Factores de Resistencia, Barreras, Desmotivadores 1. Falta de una metodología de implementación de mejoras de proceso de software definida (Niazi and Ali Babar 2008), (Niazi 2009),(Niazi, Ali Babar et al. 2010) 2. Fatal de una metodología formal (Niazi, Wilson et al. 2003),(Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 68

69 Gestión del proyecto de mejora Esta categoría refiere a considerar la iniciativa de mejora de procesos software como un proyecto con todas sus características. Factores de éxito, motivadores 1. Planificación y monitoreo del esfuerzo en mejoras de proceso de software (Dion 1999) 2. Gestión del proyecto de mejora (Stelzer and Mellis 1999), (Niazi, Wilson et al. 2003),(Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b). Factores de Resistencia, Barreras, Desmotivadores 1. Falta de gestión del proyecto (Niazi and Ali Babar 2008), (Niazi 2009),(Niazi, Ali Babar et al. 2010) 2. Problemas en la implementación (Baddoo and Hall 2003) 3. Problemas de coordinación (Baddoo and Hall 2003) Gestión del cambio cultural y organizacional Esta categoría refiere a gestionar adecuadamente los cambios a niveles cultural y organizacional derivados de la implementación de mejoras de procesos software. Factores de éxito, motivadores 1. Estrategia apropiada de transición que impacta en el cambio organizacional. (Dion 1999) 2. Agentes de cambio y líderes de opinión (Stelzer and Mellis 1999) 3. Descongelamiento de la organización (Stelzer and Mellis 1999) 4. Estabilización del proceso cambiado (Stelzer and Mellis 1999) 5. Cambios organizacionales (Baddoo and Hall 2003) 6. Aceptación de los cambios (Montoni and Rocha 2007) 7. Cultura de la compañía (Niazi, Wilson et al. 2003), (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 69

70 Factores de Resistencia, Barreras, Desmotivadores 1. Cambio de actitud de personal de gerencia y técnico (Niazi and Ali Babar 2008),(Niazi 2009), (Niazi, Ali Babar et al. 2010) 2. Falta de habilidades para implementar el cambio cultural (Brietzke and Rabelo 2006) 3. Inercia: Resistencia a nuevas prácticas (Niazi and Ali Babar 2008), (Niazi 2009), (Niazi, Ali Babar et al. 2010), (Baddoo and Hall 2003) 4. Cambios organizacionales con mala repercusión (Baddoo and Hall 2003) Autonomía (Empowerment) La categoría Autonomía refiere el grado en el que se habilita al personal dedicado a la mejora de procesos software a llevar a cabo sus actividades sin prescripción de roles o funciones específicos, así como el nivel de responsabilidad y autoridad que se les otorgue para diseñar y modificar los procesos. Factores de éxito, motivadores 1. Autonomía: equipo con la responsabilidad y autoridad para tomar decisiones en cuanto a cambios de procesos (Baddoo and Hall 2002a), (Niazi and Ali Babar 2007) 2. Propiedad del proceso (Baddoo and Hall 2002a), (Rainer and Hall 2002), (Niazi and Ali Babar 2007) Factores de Resistencia, Barreras, Desmotivadores Ninguno Carrera profesional La categoría Carrera profesional refiere a las expectativas de que la mejora de procesos software permita progresar laboral y profesionalmente, tanto dentro como fuera de la organización. 70

71 Factores de éxito, motivadores 1. Mejora de las perspectivas de carrera (Baddoo and Hall 2002a), (Niazi and Ali Babar 2007) 2. Percepción de las mejoras de proceso de software como instrumento para acceder a mejores empleos (Niazi and Ali Babar 2007) 3. Expectativas de carrera (Niazi and Ali Babar 2007) 4. Mejora en los puestos jerárquicos de la organización (Niazi and Ali Babar 2007) Factores de Resistencia, Barreras, Desmotivadores Ninguno Motivación Esta categoría implica la identificación de factores que propician a que las personas se sientan atraídas a participar en las actividades de mejora de procesos de software. Factores de éxito, motivadores 1. Motivación y aceptación de la mejora de proceso de software (Montoni and Rocha 2007) 2. Satisfacción laboral (Niazi and Ali Babar 2007) 3. Actitud: nivel en que una persona tiene una evaluación favorable o desfavorable del comportamiento en cuestión (Umarji and Emurian 2005) 4. Intención: aspectos motivacionales que influencian el comportamiento (Umarji and Emurian 2005) 5. Voluntariedad: grado en que las personas que acogerán la decisión de la adopción de forma voluntaria (Riemenschneider and Hardgrave 2002) 6. Afectación: refiere a las reacciones emocionales positivas o negativas que un individuo asocia con un acto particular (Riemenschneider and Hardgrave 2002) 7. Consecuencias de Carrera (Riemenschneider and Hardgrave 2002) Factores de Resistencia, Barreras, Desmotivadores 1. Miedo a consecuencias adversas (Umarji and Emurian 2005) 71

72 Mediciones La categoría Mediciones refiere a contar con métricas que permitan realizar el seguimiento de las actividades de mejora de procesos y detectar desvíos en los avances previstos. Factores de éxito, motivadores 1. Preocupación por la medición (Dyba 2000), (Dyba 2003), (Dyba 2005) 2. Métricas (Rainer and Hall 2002) 3. Medición (Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) Factores de Resistencia, Barreras, Desmotivadores 1. Métricas inadecuadas (Baddoo and Hall 2003) Rotación La categoría Rotación de personal refiere a la ocurrencia de cambios en el conjunto de las personas dedicadas a las actividades de mejora de procesos software. Factores de éxito, motivadores Ninguno Factores de Resistencia, Barreras, Desmotivadores 1. Rotación del personal (Baddoo and Hall 2003), (Emam, Goldenson et al. 1998), (Niazi and Ali Babar 2008),(Niazi 2009), (Niazi, Ali Babar et al. 2010) Otros factores La categoría Otros factores agrupa aquellos factores que son mencionados marginalmente en la literatura analizada y que no ameritan tener su propia categoría, o bien porque su significado no está claro a partir del contexto del artículo que lo menciona. 72

73 Factores de éxito, motivadores 1. Revisiones e Inspecciones (Rainer and Hall 2002), (Niazi, Wilson et al. 2003),(Niazi, Wilson et al. 2004a; Niazi, Wilson et al. 2004b) 2. Factores personales (Baddoo and Hall 2003) Factores de Resistencia, Barreras, Desmotivadores 1. Conflictos de interés que frustren las iniciativas (Baddoo and Hall 2003) 2. Presiones comerciales (Baddoo and Hall 2003) 73

74 6 Relación de categorías de factores con las áreas de proceso del People CMM A partir de esta agrupación en categorías descripta en el capitulo anterior, se relacionan las áreas del People CMM que facilitan los factores de éxito y mitigan las barreras organizacionales. El criterio para establecer estas relaciones es que, dada una categoría de factores exista una o más áreas de proceso tales que, por sus propósitos y objetivos, la implementación de sus prácticas asociadas pueda contribuir a fortalecer los factores de éxito y motivadores, así como a mitigar los factores de resistencia, barreras y desmotivadores asociados a esa categoría. La aplicación de este criterio dio como resultado que 11 de las 24 categorías de factores descriptas en la sección 74

75 , pueden relacionarse con una o más áreas de procesos de People CMM, como muestra la Tabla 6.1. Tabla 6.1 Relación de categorías con People CMM En base a las descripciones de estas categorías presentadas en la sección 75