PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA MEJORA DE PROCESOS DE SOFTWARE EN UNA PEQUEÑA ORGANIZACIÓN DESAROLLADORA DE SOFTWARE: CASO PROCAL-PROSER-LIM.DELTA- 1 ER CICLO Tesis para optar por el Título de Ingeniero Informático, que presenta el bachiller: ANDRÉS MARINO EDUARDO SUAREZ BAZÁN ASESOR: ABRAHAM ELISEO DÁVILA RAMÓN CO-ASESOR: LUIS ALBERTO FLORES GARCÍA Febrero- 2015 2 Resumen El presente trabajo se realizó basándose en los problemas detectados en la industria de software; en concreto, en el sector de las pequeñas organizaciones desarrolladoras de software. Para ello se identificó que el problema principal que éstas presentan es la entrega de productos de baja calidad fuera del tiempo acordado con el cliente. Este problema surge por una inadecuada gestión de los proyectos de software, el uso de indicadores, métricas y controles ineficientes, la realización de procesos repetitivos o que no generan valor; y finalmente, porque los responsables toman acciones reactivas y no planificadas. Es por ello que este trabajo consiste en la ejecución de un ciclo de mejora de procesos de una pequeña organización desarrolladora de software. Para ello se realizó una evaluación inicial de los procesos de la empresa, luego se planificó la mejora de los procesos seleccionados, se ejecutó la mejora de acuerdo al plan establecido. Posteriormente, se realizó una evaluación final de la mejora plasmada y se evaluó el esfuerzo desarrollado. Finalmente, se elaboró un reporte técnico para la empresa. Este proyecto se justificó debido a que aporta beneficios a la empresa (crecimiento, beneficio económico procesos eficientes) a sus trabajadores y a sus clientes (incremento de la satisfacción de los trabajadores y clientes, cumplimiento de plazos de entrega y simplificación del trabajo); y si se tiene una visión macro, puede impactar positivamente en la sociedad incrementando la demanda de trabajo si se experimenta un crecimiento económico en los clientes de la empresa. El proyecto se sustentó teóricamente en el modelo de procesos ISO/IEC 29110-5-1-2: Guía de Gestión e Ingeniería: Grupo Perfil Genérico: Perfil Básico y la 29110-5-1-3: Guía de Gestión e Ingeniería: Grupo Perfil Genérico: Perfil Intermedio. Este modelo (ISO/IEC 29110-5-1) adapta los modelos aplicados a grandes empresas (por ejemplo, ISO 9001, CMMI, ISO/IEC 12207 e ISO/IEC 15504) para adaptarlos a las pequeñas organizaciones. Ya que notaron que estas últimas están limitadas al costo, tiempo, recursos, adaptabilidad, etc. Así mismo, se utilizó la evaluación de procesos basado en la ISO/IEC 15504. 3 4 5 Agradecimientos Este trabajo ha sido realizado dentro del proyecto "ProCal-ProSer Determinación de factores que influyen en la PROductividad y CALidad en organizaciones que desarrollan PROductos software y ofrecen SERvicios software utilizando como base normas ISO en pequeñas organizaciones" bajo el Contrato 210-FINCYT-IA-2013 y parcialmente soportado por el Departamento de Ingeniería de la Pontificia Universidad Católica del Perú. 6 Índice 1 INTRODUCCIÓN ______________________________________________ 10 1.1 LA INDUSTRIA DEL SOFTWARE EN EL PERÚ ______________________________ 10 1.2 EL PROYECTO COMPETISOFT EN EL PERÚ _____________________________ 12 1.3 EL PROYECTO PROCAL-PROSER ______________________________________ 13 1.4 EL COMPONENTE MEJORA DE PROCESO EN DESARROLLO DE SOFTWARE ________ 13 2 PROPUESTA DEL PROYECTO DE TESIS ________________________15 2.1 OBJETIVOS, RESULTADO Y ALCANCE ___________________________________ 15 2.1.1 OBJETIVO GENERAL ______________________________________________ 15 2.1.2 OBJETIVOS ESPECÍFICOS: __________________________________________ 15 2.1.3 RESULTADOS ESPERADOS __________________________________________ 15 2.1.4 ALCANCE ______________________________________________________ 16 2.2 HERRAMIENTAS , MÉTODOS Y PROCEDIMIENTO ___________________________ 17 2.2.1 INTRODUCCIÓN __________________________________________________ 17 2.2.2 HERRAMIENTAS _________________________________________________ 18 2.2.3 MÉTODOS Y PROCEDIMIENTOS ______________________________________ 18 2.3 JUSTIFICACIÓN Y VIABILIDAD DEL PROYECTO ____________________________ 19 2.3.1 JUSTIFICATIVA __________________________________________________ 19 2.3.2 VIABILIDAD_____________________________________________________ 20 2.4 PLAN DE TRABAJO _________________________________________________ 21 3 MARCO DE REFERENCIA _____________________________________ 23 3.1 MARCO CONCEPTUAL ______________________________________________ 23 3.1.1 PROCESO ______________________________________________________ 23 3.1.2 CALIDAD _______________________________________________________ 23 3.1.3 CAPACIDAD DE PROCESO___________________________________________ 23 3.1.4 MODELO _______________________________________________________ 23 3.1.5 MADUREZ DE LA ORGANIZACIÓN ____________________________________ 23 3.2 MODELOS PARA PROCESO SOFTWARE __________________________________ 23 3.2.1 MODELO DE PROCESOS ____________________________________________ 24 3.2.2 MODELO DE MEJORA DE PROCESOS___________________________________ 28 3.2.3 MODELO DE EVALUACIÓN DE PROCESOS _______________________________ 33 3.3 EXPERIENCIAS DE MEJORA __________________________________________ 36 3.3.1 TESIS DE COMPETISOFT-PERÚ ______________________________________ 36 3.3.2 EXPERIENCIAS DE MOPROSOFT _____________________________________ 37 3.3.3 PROBLEMAS EN MEJORA D E PROCESOS EN PYMES ________________________ 37 3.4 INGENIERIA DE SOFTWARE. PERFILES DEL CICLO DE VIDA PARA LAS PEQUEÑAS ORGANIZACIONES (PO). _________________________________________________ 38 3.4.1 ESTRUCTURA DE LA NORMA ________________________________________ 38 3.4.2 VSE PERFIL BÁSICO ______________________________________________ 39 3.4.3 PERFIL ORGANIZACIONAL _________________________________________ 40 4 MEJORA DEL PROCESO _______________________________________ 42 4.1 DESCRIPCIÓN DE LA EMPRESA ________________________________________ 42 7 4.2 EVALUACIÓN DIAGNÓSTICA DE LA EMPRESA _____________________________ 43 4.2.1 PROPÓSITO DE LA EVALUACIÓN _____________________________________ 43 4.2.2 OBJETIVOS DE NEGOCIO ___________________________________________ 43 4.2.3 PROCESOS EVALUADOS ____________________________________________ 43 4.2.4 PERFIL DE CAPACIDADES __________________________________________ 44 4.2.5 RESULTADO OBTENIDOS ___________________________________________ 45 4.3 PLAN DE MEJORA DE PROCESOS _______________________________________ 54 4.3.1 PRIORIZACIÓN DE PROCESOS _______________________________________ 55 4.3.2 PROPUESTA DEL PLAN DE MEJORA ___________________________________ 58 4.4 EJECUCIÓN DE LAS MEJORAS _________________________________________ 76 4.5 EVALUACIÓN DE LAS MEJORAS _______________________________________ 81 4.6 PROBLEMAS IDENTIFICADOS Y ACCIONES TOMADAS _______________________ 83 5 OBSERVACIONES, CONCLUSIONES Y MEJORA ______________ 85 5.1 OBSERVACIONES __________________________________________________ 85 5.2 CONCLUSIONES ___________________________________________________ 86 5.3 RECOMENDACIONES _______________________________________________ 87 REFERENCIAS BIBLIOGRÁFICAS ________________________________ 89 8 Índice de imágenes Figura 3.1 Sistema Gestión de Calidad [29] ______________________________________________ 25 Figura 3.2 Niveles de madurez según CMMI. Adaptado de [24] __________________________ 26 Figura 3.3 Modelo de Proceso ISO/IEC 12207 [8] ________________________________________ 27 Figura 3.4 Modelo MoProsoft [29] ________________________________________________________ 28 Figura 3.5 Etapas del modelo IDEAL. Adaptado de [30] _________________________________ 29 Figura 3.6 Componentes del Modelo MPS [31]___________________________________________ 30 Figura 3.7 Modelo de procesos de COMPETISOFT [33] __________________________________ 32 Figura 3.8 Estructura de la ISO 15504 [34] ______________________________________________ 34 Figura 3.9 Niveles de Madurez de la parte7 [34] _________________________________________ 34 Figura 3.10 Niveles de capacidad [23] ___________________________________________________ 36 Figura 3.11 Estructura de la norma ISO/IEC 29110 [54] __________________________________ 39 Figura 3.12 Procesos del perfil básico VSE [16] _________________________________________ 40 Figura 4.1 Organigrama de LIM.DELTA __________________________________________________ 44 Figura 4.2 Perfil de capacidades _________________________________________________________ 45 Figura 4.3 Distribución de puntuación de la Gestión de Proyecto _______________________ 46 Figura 4.4 Distribución de puntuaciones de Implementación de Software ______________ 47 Figura 4.5 Distribución de puntuación del Portafolio de Proyectos _____________________ 49 Figura 4.6 Distribución de puntuación de Gestión de Recursos _________________________ 50 Figura 4.7 Distribución de puntuación de Gestión de Procesos _________________________ 52 Figura 4.8 Mapa de Procesos Inicial del Portafolio de Proyectos ________________________ 61 Figura 4.9 Mapa de Procesos Inicial de la Implementación de Software _________________ 64 Figura 4 .10 Mapa de Proceso Inicial de la Gestión de Proyecto __________________________________ 65 Figura 4 .11 Mapa de Procesos de la Preventa _________________________________________________ 66 Figura 4 .12 Mapa de Procesos Final de Portafolio de Proyectos _________________________________ 72 Figura 4 .13 Mapa de Proceso Final de la Implementación de Software (Proyectos Nuevos) _________ 73 Figura 4 .14 Mapa de Procesos del Mantenimiento de Software (Proyectos de Actualización) _______ 74 Figura 4 .15 Mapa de Procesos Final de la Gestión de Proyecto __________________________________ 75 Figura 4 .16 Perfil de capacidades_____________________________________________________________ 81 9 Índice de tablas Tabla 2.1 Riesgos identificados en el proyecto. Autoría propia__________________________ 17 Tabla 2.2 Resultados esperados vs Herramientas. Autoría propia_______________________ 18 Tabla 2.3 Beneficios del proyecto. Autoría propia _______________________________________ 20 Tabla 2.4 Actividades de la inducción ___________________________________________________ 21 Tabla 2.5 Actividades de la evaluación __________________________________________________ 21 Tabla 2.6 Actividades de la planificación de la mejora___________________________________ 22 Tabla 2.7 Actividades de la implementación de la mejora _______________________________ 22 Tabla 2.8 Actividades del cierre__________________________________________________________ 22 Tabla 4.1 Porcentaje de cumplimiento por proceso evaluado ___________________________ 45 Tabla 4.2 Pesos asignados a los objetivos de negocio __________________________________ 56 Tabla 4.3 Peso de los problemas de negocio ___________________________________________ 56 Tabla 4.4 Objetivos de negocio vs Problemas de negocio _______________________________ 57 Tabla 4.5 Problemas de negocio vs. Procesos___________________________________________ 58 Tabla 4 .6 Objetivo de Mejora/Objetivos de Negocio/Problemas del Portafolio de Proyectos _______ 68 Tabla 4.7 Objetivo de Mejora/Objetivos de Negocio/ Problemas de la Implementación de Software ____________________________________________________________________________ 69 Tabla 4 .8 Objetivo de Mejora/Objetivos de Negocio/ Problemas de la Gestión de Proyecto ________ 71 Tabla 4 .9 Nivel de cumplimiento de procesos al final del ciclo de mejora ________________________ 81 Tabla 4 .10 Comparativo Inicial vs. Final del nivel de cumplimiento de cada proceso _______________ 82 Tabla 4 .11 Esfuerzo del proyecto (en horas) ___________________________________________________ 83 1 Introducción En los últimos años, el Perú ha estado experimentando un crecimiento económico sostenible por efectos de la globalización (13 años de crecimiento continuo) [1]. Esto se ve reflejado en el porcentaje de 6.8% de desempeño económico que alcanzó en 2011; es así que, se ha proyectado para los siguientes años mantener dicho porcentaje entre 5.5 y 6.5% [2]. Aunque la inflación que se ha registrado está por encima del 3%, esta no ha generado amenazas o especulaciones relacionadas con riesgos macroeconómicos futuros [1]. De acuerdo a estas estadísticas, no cabe duda de que el Perú ha tenido un buen periodo de “vacas gordas” en los últimos años; en donde si bien tuvo ciertos riesgos económicos, estos no tuvieron un impacto relevante en su economía. Como consecuencia de este crecimiento, muchos sectores del país se han visto beneficiados, entre ellos se encuentra la industria del software [3]. 1.1 La industria del software en el Perú Esta industria, a pesar de tener poco tiempo en el mercado- 17años, ha sido seleccionada por el sector privado para localizar posibles destinos de exportación debido a la tasa de crecimiento que presenta (aproximadamente 15% anual) [1]. Sin embargo, esta cifra está constituida por aquellas empresas que presentan ventajas competitivas, grandes corporaciones; es decir, por aquellas en las que es verificable la capacidad y calidad de sus procesos (conjunto de actividades que transforman entradas en resultados [4]) y de los productos finales (software y servicios de TI) [5]. En ese sentido, son las pequeñas organizaciones las que se han quedado atrás en este crecimiento ya que no han demostrado tener la madurez suficiente y capacidad necesaria en sus procesos. Se entiende por madurez como el grado consistente con el que una organización ha ejecutado sus procesos y por capacidad de procesos como el rango en que un proceso logra los resultados esperados [6]. Según García, una de las dificultades que afronta el entorno informático en la actualidad es la calidad del software [7]. La calidad se define, de acuerdo a la ISO, como el nivel en que se cumplieron los requerimientos desde el inicio hasta el final [8]. Son pocas las empresas que siguen estándares, buenas prácticas como CMMI o normas como ISO 9000 o ISO/IEC 12207 por diferentes razones (costo, tiempo, recursos, adaptabilidad etc.) [9]. Estas son importantes para los clientes; pues, éstas dan crédito de la seguridad y calidad de los productos [10]. Dentro de estas buenas prácticas se establecen modelos de procesos, de evaluación de procesos y modelos de mejora de procesos. Un modelo de procesos es una guía para el diseño, análisis y la revisión de los procesos de software [11], un modelo de evaluación permite asegurar la calidad a través de indicadores y/o 11 métricas para los distintos procesos [12] y un modelo de mejora incrementa la calidad de los procesos con el fin de cubrir efectiva y eficazmente los requerimientos [4]. Según COMEX, las pequeñas y medianas empresas son las que carecen de estas certificaciones (CMMI o ISO/IEC 15504); puesto que, estas escapan de su presupuesto por el precio elevado que poseen o porque simplemente no se aplican a las dimensiones de la empresa [2]. Carecer de un sistema apropiado para gestionar el rumbo de una empresa desarrolladora de software indudablemente desencadena diversos problemas. La incorrecta gestión de los proyectos de software es una de las principales dificultades a tratar. Ya que si se dirige un proyecto desde el inicio sin objetivos claros, pobre planificación, gestión de riesgos ausente, mala comunicación entre otros puntos, entonces definitivamente el proyecto terminará por fracasar o si se finaliza, este no cumplirá con lo solicitado por los interesados [13]. Todo lo opuesto sucedería si se tuviese una guía de referencia que ayude a gestionar el proyecto de software [14] La presencia de indicadores, métricas y controles de calidad ineficientes para los procesos de software es otro de los inconvenientes que pueden surgir. Cuando estos parámetros no son seleccionados de manera estricta y precisa entonces las señales de alerta y los cambios del sistema corren peligro de pasar inadvertidos; asimismo, no se puede estimar, evaluar y demostrar el progreso de los proyectos de software y mucho menos detectar áreas de problemas potenciales [11]. Es importante evaluar correctamente los procesos ya que también permite identificar oportunidades de mejora y redirigir el esfuerzo hacia estos procesos con la finalidad de alcanzar los objetivos del negocio [15]. Por otro lado, realizar procesos de software repetitivos o procesos que no generen valor es otro de los problemas que las empresas desarrolladoras de software tienen que afrontar por no manejar un marco de referencia aplicable [16]. El efecto de repetir un proceso de software que ya se realizó anteriormente origina un gasto innecesario así como una mala distribución de los recursos con los que se cuenta para el desempeño de los proyectos [17]. Asimismo, es riesgoso tomar acciones inmediatas o reactivas cuando no se ha tenido una previa planificación ante fallas [18]. Puesto que, esto puede originar pérdidas para la empresa de gran magnitud y hasta podría llegar a interferir con la continuidad del 12 negocio [18]. Este es otro de los problemas que se suelen presentar cuando no hay un seguimiento de buenas prácticas reconocidas. Sin embargo, las empresas de software no solo deben enfrentar esas dificultades sino también la satisfacción del cliente que es de vital importancia para manejar una amplia cartera de clientes [19]; el prestigio de la empresa está en juego si es que los procesos de software son ineficientes [20]; el volumen de ventas podría estar en decadencia si es que no se cumple con los requerido por los interesados [21]; la competitivad de la empresa con respecto a las demás determinará su permanencia en el mercado de software [22]. No obstante, las alternativas de solución a estos problemas no están dentro del alcance de este trabajo; sino que serán objeto de estudio para trabajos futuros. Para el presente trabajo de fin de carrera se ha tomado como caso a una pequeña organización desarrolladora de software. En esta, se evaluó su situación actual y se realizó una evaluación diagnóstica para determinar los problemas que esta presentaba. Finalmente, a través de la ejecución de un ciclo de mejora se aspiró resolver estos tipos de problemas detectados. En el Perú, la NTP-ISO/IEC 12207 la cual provee un marco de referencia que abarca todo el ciclo de vida del software (desde la conceptualización de ideas hasta su retirada) y consta de un conjunto de buenas prácticas para la adquisición y suministración de productos y servicios de software [23]. También se cuenta con la norma NTP-ISO/IEC 29110 la cual es una traducción de la ISO/IEC 29110 y está orientada a ser una guía de referencia para el desarrollo de software [16]. Estas se adaptan perfectamente a la necesidad que tienen las pequeñas organizaciones [16] y es, por ello, que sobre estas se ha trabajado el presente proyecto de fin de carrera. 1.2 El proyecto COMPETISOFT en el Perú El proyecto Competisoft-PUCP fue liderado por el GIDIS (Grupo de Investigación y Desarrollo en Ingeniería de Software) de la PUCP a cargo del investigador Abraham Dávila. El Proyecto buscaba la mejora continua de los procesos de software utilizados por Pymes a través de la adaptación de un modelo de procesos acorde con el negocio de cada empresa basado en la metodología COMPETISOFT [24]. El proyecto se denominó “Mejora de proceso de software de una empresa desarrolladora de software: COMPETISOFT-PERÚ “. En él trabajaron un conjunto de estudiantes de pregrado y postgrado de Lima, Arequipa y Trujillo. Este arduo trabajo sirvió como 13 proyecto de fin de carrera para estudiantes de pregrado de la PUCP y otras universidades. El despliegue del trabajo consistió en asignar a un tesista a una empresa comprometida con el proyecto. Para respetar data sensible y evitar la divulgación de información, se firmó un documento de confidencialidad. Actualmente se han registrado once tesis en la PUCP bajo el nombre ya mencionado en líneas anteriores y el proyecto de cada tesista consta de dos fases (1er ciclo y 2do ciclo) debido a que fue establecido en COMPETISOFT–PUCP [24]. 1.3 El proyecto ProCal-ProSer El proyecto ProCal-ProSer (Productividad y Calidad en Productos y Servicios software) tiene como objetivo fundamental determinar cuáles son los factores claves que afectan la mejora de procesos para alcanzar la competitividad (productividad y calidad) entre las organizaciones que desarrollan software y entre las que ofrecen servicios de software. Este proyecto es dirigido por el grupo de investigación y desarrollo en ingeniería de software de la PUCP (GIDIS-PUCP) y tiene como participantes a la Universidad Nacional de San Agustín, la Universidad Privada del Norte, la Asociación de Productores de Software y, finalmente, a la Escuela Politécnica de la Universidad de Sao Paulo [25]. ProCal-ProSer está compuesto de dos grandes líneas de trabajo. La primera enfoca la mejora de procesos en las organizaciones que desarrollan software a través de una estructura de pruebas controladas usando la normativa ISO/IEC29110. Por otro lado, la segunda enfoca ésta mejora en organizaciones que ofrecen servicios de software bajo una modalidad, también, de pruebas controladas, pero usando un modelo propio, basado en las normas ISO/IEC 29110 como ISO/IEC 20000 [25]. Este proyecto aplica la misma metodología que COMPETISOFT-PUCP (tesistas de pregrado trabajando en pequeñas organizaciones) y se ha previsto que finalizará en diciembre del 2016. 1.4 El componente mejora de proceso en desarrollo de software Para realizar un ciclo de mejora se debe primero realizar una inducción en la organización. Ésta inducción se basa principalmente en la recopilación de información relevante como procesos claves, proyectos en los últimos años, infraestructura informática, personal, objetivos de negocio, problemas detectados y toda la data que 14 pueda influir directa o indirectamente en la performance de los procesos de software. Luego de esto, se debe realizar una evaluación diagnóstica con la cual se pueda llegar a conocer el grado de cumplimiento de los procesos de la organización con respecto a la norma o modelo. Así mismo, con ayuda de los problemas detectados, los procesos evaluados y los objetivos del negocio, se pueden seleccionar los procesos que tienen mayor trascendencia en la organización para proponer una posible mejora. Una vez seleccionado el o los procesos, se aplica la mejora propuesta y se vuelve a realizar una evaluación final. Para terminar con el ciclo actual de mejora, se genera un reporte en donde se muestra una comparación entre el antes y el después de la ejecución de la mejora para medir la calidad que tuvo ésta. 15 2 Propuesta del proyecto de tesis La propuesta del presente proyecto está enfocada en la ejecución de un primer ciclo de mejora bajo la norma ISO/IEC 29110. Para el desarrollo y éxito del proyecto se plantearon los objetivos a lograr y los resultados que se esperaban obtener. Así mismo, se identificaron los principales riesgos y las limitaciones que tuvo el proyecto. Por otro lado, se mencionan las herramientas que se emplearon, la viabilidad del proyecto realizada así como el plan de trabajo que se elaboró para ejecutar el proyecto. 2.1 Objetivos, resultado y alcance En esta sección se detalla el objetivo general que tuvo el presente trabajo de fin de carrera. Así mismo, se explica los objetivos específicos que se trazaron para lograr el propósito de la implantación de la norma ISO/IEC 29110. De igual manera, se precisa los resultados que se esperaban obtener antes de la ejecución del ciclo de mejora así como los límites a los que se tuvo que restringir el Proyecto. 2.1.1 Objetivo General El objetivo del presente trabajo consiste en ejecutar un ciclo de mejora de los procesos de software en una pequeña organización desarrolladora de software del mercado peruano. 2.1.2 Objetivos Específicos: Los objetivos específicos son los siguientes:  Realizar una evaluación inicial de los procesos de la empresa desarrolladora de software.  Realizar la planificación de la mejora en la empresa.  Ejecutar un ciclo de mejora de acuerdo al plan de trabajo establecido.  Realizar una evaluación final de la mejora realizada.  Evaluar el esfuerzo desarrollado respecto de la mejora obtenida.  Elaborar el reporte técnico correspondiente para la empresa. 2.1.3 Resultados Esperados Los resultados que se esperan obtener al finalizar el proyecto son los siguientes:  Informe técnico de evaluación inicial de procesos: Objetivo 1.  Plan de mejora de procesos: Objetivo2.  Propuestas de mejora ajustadas al entorno de la empresa: Objetivo 3.  Evaluación final del ciclo de mejora: Objetivo 4 y 5. 16  Informe técnico final que refleja el antes y el después : Objetivo 6 2.1.4 Alcance El proceso de mejora se aplicó a una pequeña organización de software comprometida con el proyecto. La empresa representa el caso LIM.DELTA de una lista mayor de pequeñas organizaciones desarrolladoras de software. El Proyecto cubre desde el análisis de la situación actual y concluye con el reporte técnico que incluye la evaluación final y directrices para iniciar un nuevo ciclo de mejora, Además, se presentarán las lecciones aprendidas en el proceso del ciclo de mejora seguido y la evaluación del esfuerzo desarrollado en la mejora de proceso. El ciclo de mejora se implementó en la empresa “LIM.DELTA”, identificada con esta letra griega para mantener la confidencialidad del caso. 2.1.4.1 Limitaciones A continuación se detalla las posibles limitaciones que el presente Proyecto podría tener durante su ejecución y que podrían afectar en la consecución de los objetivos específicos.  Durante el levantamiento de información, el personal podría responder sin objetividad o solo completar las encuestas, cuestionario, etc. por rellenar. En ese sentido, la información podría presentar cierto margen de error.  La cultura organizacional de la empresa podría ser otro factor que afecte en el éxito del proyecto; puesto que, la organización ya ha venido trabajando con un patrón establecido y es difícil siempre cambiar algo a lo que ya se está acostumbrado (resistencia al cambio).  La falta de compromiso por parte de la alta dirección, podría ser un obstáculo ya que el personal siempre mira a sus superiores y si no ve en ellos esa determinación y exigencia hacia sus trabajadores entonces estos simplemente no se involucrarán en el proyecto tampoco.  El presupuesto que maneja la empresa para el proyecto es también limitado. 2.1.4.2 Riesgos Por otro lado, se identificaron un conjunto de riesgos (ver tabla 2.1) a los cuales el proyecto podría estar expuesto, así como el impacto que podrían tener si llegaran a ocurrir; y finalmente, las acciones correctivas que se deberían seguir para mitigar las consecuencias. 17 Tabla 2.1 Riesgos identificados en el proyecto. Autoría propia Riesgo identificado Impacto en el proyecto Medidas correctivas para mitigar Retraso en los entregables previstos para una determinada fecha. Medio En tal sentido, se debería aumentar las horas de trabajo del responsable para que se alinee con lo solicitado para la fecha y para el próximo entregable. Errores en estimaciones y/o cálculos de tiempo y costo. Medio Se debe revisar dos veces o tres veces los resultados, compararlos y analizar si es razonable su valor. Así mismo, se puede necesitar de un tercero para que corrobore los resultados (asesor, co- asesor, etc.) Negación de la propuesta de mejora. Medio Si esto ocurriese, se debe tener una segunda propuesta de mejora a fin de prever este evento. Así mismo, se debe tener otro juego de proyectos a ser mejorados en caso la segunda propuesta sea rechazada. Presentación de su carta de renuncia por parte del responsable del área de TI por motivos personales. Alto En tal caso, se debería conversar con la alta dirección para que designe a otro profesional capaz de asumir el cargo (este debe reunir las características principales del puesto). Extravío de la información recolectada por descuido. Medio Para prever este caso se debe tener la información guardada en más de un lugar (en la pc, en la nube, un USB, etc.). 2.2 Herramientas, métodos y procedimiento En esta sección se mencionan las herramientas más relevantes que se utilizaron para el trabajo de fin de carrera. Así mismo, se detallan los métodos y procedimiento que hicieron que el Proyecto se desarrolle eficientemente. 2.2.1 Introducción A continuación se presenta la tabla 2.2 en donde se muestra la relación entre los resultados esperados y las herramientas que se usarán para obtenerlo 18 Tabla 2.2 Resultados esperados vs Herramientas. Autoría propia Resultados Esperados Herramientas R1:Informe técnico de evaluación inicial de procesos Microsoft Word. También se usará el formato del informe técnico proporcionado por el proyecto ProCal- ProSer R2: Plan de mejora de procesos Microsoft Project, Microsoft Visio, Web2 Projetct R3: Propuestas de mejora ajustadas al entorno de la empresa: Microsoft Visio, Microsoft Excel. Matriz FODA, Matriz RACI. Priorización de procesos R4: Evaluación final del ciclo de mejora ISO/IEC 15504-2 Plantillas y formatos. R5: Informe técnico final que refleja el antes y el después Microsoft Word y Microsoft Excel. 2.2.2 Herramientas Microsoft Visio Esta herramienta se usará para ilustrar los casos de uso de los procesos sobre los cuáles se ejecutará el ciclo de mejora. También será manipulada para hacer flujogramas de los procesos y otros diagramas que requieran de este para ayudar a ilustrar mejor lo que se está proponiendo o explicando. Matriz FODA Esta herramienta ayudará a identificar la situación actual de la empresa y permitirá identificar qué puntos necesitan urgente atención. Así mismo, ayudará a contrastar el estado después de ejecutado el ciclo de mejora con el estado previo. Con la finalidad de escoger aquellos procesos que presentan alta prioridad de ser sometidos al ciclo de mejora se usarán los criterios de objetivos de negocio versus problemas del negocio y problemas de negocio versus procesos del modelo. Los procesos con puntuaciones más altas serán priorizados si la Empresa está de acuerdo. 2.2.3 Métodos y Procedimientos Para este proyecto, se considerará la ISO/IEC 29110 (VSE perfil básico) y se referenciará también al modelo MoProsoft. Estos modelos de procesos serán usados como referencia para poder identificar los procesos que la empresa ya tiene en ejecución así como aquellos que no ha incorporado aún a su entorno y que son de vital importancia para su correcto funcionamiento. Por otro lado, se empleará el modelo de evaluación 19 ISO/IEC 15504 para medir la capacidad de los procesos de la organización y determinar el nivel de madurez de la Empresa antes y después de ejecutado el ciclo de mejora. 2.3 Justificación y viabilidad del proyecto En este capítulo se detalla los motivos por los cuales se desea llevar a cabo el Proyecto, indicando los beneficios y el impacto que tendría sobre la sociedad. Por otro lado, se explicará si es posible o no realizar el Proyecto, es decir, la viabilidad del presente trabajo. 2.3.1 Justificativa En diferentes proyectos de mejora de procesos realizados en empresas desarrolladoras de software se han obtenido diferentes resultados. Estos han sido analizados por diferentes investigadores y han concluido que en la mayoría de casos se han visualizado ventajas similares en aquellas empresas que fueron sometidas a ciclos de mejora. A continuación, se lista esos beneficios en común que se registraron [26]:  La satisfacción del cliente mejoró por el uso de software con menos cantidad de errores.  La eficiencia de los procesos de desarrollo aumentó.  La satisfacción de los trabajadores también se incrementó por la simplificación del trabajo y porque ahora contaban con herramientas y recursos aptos para realizar sus labores.  Se facilitó la definición y cumplimiento de los objetivos de calidad.  Se redujo el esfuerzo en pruebas de software.  El tiempo de entrega del producto se redujo. De este listado de beneficios se puede notar que el primer favorecido del proyecto de mejora es el dueño de la organización ya que la rentabilidad de su negocio se incrementará al no tener que realizar gastos innecesarios y adicionales para componer los errores que sus productos tenían. El prestigio de su empresa se elevará a raíz de la calidad de sus productos. Por otro lado, también se puede percibir que los clientes del negocio serán beneficiados, ya que, se les entregará productos de mayor calidad en el tiempo oportuno para desempeñar sus procesos de negocio. En tercer lugar, los trabajadores serán favorecidos; puesto que, el esfuerzo de su trabajo será menor. Ya no tendrán que repetir actividades por entregar productos defectuosos. Así mismo, su trabajo se simplificará 20 porque tienen las herramientas indicadas para llevarlo a cabo. Estos puntos se visualizan en la Tabla 2.3. Esta perspectiva de beneficiados se puede abstraer como una reacción en cadena y a partir de ella percibir el impacto que origina en la sociedad. Si los productos de software se entregan a tiempo y la calidad de este es de gran magnitud (errores casi imperceptibles) entonces los clientes de las diferentes empresas podrán llevar a cabo sus actividades de manera eficaz y eficiente. Sus negocios prosperarán si es que además de la tecnología sus demás procesos también siguen estándares de calidad reconocidos. Por lo tanto, si las empresas de los diferentes rubros crecen, necesitarán mayor cantidad de trabajadores (la demanda de trabajo aumenta) en tal sentido, la tasa de desempleo en la sociedad se reducirá y traerá consigo más oportunidades de desarrollo para la población. Tabla 2.3 Beneficios del proyecto. Autoría propia Financiero Clientes Crecimiento y beneficio económico para la empresa Incremento de la satisfacción Eficiencia del proceso de desarrollo. Incremento de la satisfacción Cumplimiento de los objetivos de la calidad. 2.3.2 Viabilidad El proyecto será posible de realizar debido a que se cuenta con los recursos necesarios para la puesta en marcha. La empresa firmará un compromiso con la PUCP en donde ésta se hará responsable de brindar la información pertinente al alumno quién a su vez respetará la confidencialidad de dicha información. En cuanto al marco teórico, el alumno recibió una capacitación de veinte horas en donde interiorizó conceptos, participó de talleres y resolvió dudas que encontró en el camino. Adicionalmente, en términos económicos, el proyecto es financiado con fondos del gobierno y a su vez, la empresa cuenta con un presupuesto establecido para el proyecto. De esta manera, el alumno tendrá presente estas consideraciones al momento de realizar la(s) propuesta(s) de mejora. En conclusión, considerando los principales factores antes mencionados, la viabilidad del proyecto está asegurada. 21 2.4 Plan de trabajo El propósito de este plan de trabajo es describir el conjunto de actividades de alto nivel que se deben de realizar y los resultados que se deben obtener como parte del proceso de mejora para la Organización. Las tareas previstas para el Proyecto se presentan organizadas por componentes indicando los productos que se obtienen. Los componentes y tareas del servicio son:  Componente 1. Inducción en la Organización. Este componente comprende la descripción de la organización, el levantamiento preliminar de los procesos tal como son realizados en la Organización. El detalle se puede observar en la Tabla 2.4. Tabla 2.4 Actividades de la inducción Actividad Producto Elaborar el Plan Base del Proyecto Plan Base del Proyecto (PBP) Elaborar el Informe de caracterización Informe de Caracterización de la Organización (ICO)  Componente 2. Evaluación Diagnóstica de Procesos. Este componente comprende la evaluación de los procesos previstos en la NTP-RT- ISO/IEC 29110:5-1-2:2012 (perfil Básico) y la ISO/IEC DTR 29110-5-1-3:2012 (perfil Intermedio). El detalle se puede observar en la Tabla 2.5. Tabla 2.5 Actividades de la evaluación Actividad Producto Elaborar el plan de evaluación de procesos Plan de Evaluación de Procesos (PEP) Elaborar del Informe de Evaluación de procesos Informe de Evaluación de procesos (IEP)  Componente 3. Planificación de la Mejora de Procesos Este componente comprende el desarrollo de un plan de mejora de procesos considerando las metas a ser logradas y los problemas a ser resueltos por los procesos seleccionados para la iteración. El detalle se puede observar en la Tabla 2.6. 22 Tabla 2.6 Actividades de la planificación de la mejora Actividad Producto Elaborar el plan de mejora de proceso Plan de mejora de procesos Elaborar propuestas de mejora de proceso en cada proceso considerado Definición de procesos (patrón de procesos) Definición o mejora de formatos  Componente 4. Implementación de la Mejoras. Este componente comprende la capacitación del personal y la realización del piloto de la mejora definida. El detalle se puede observar en la Tabla 2.7. Tabla 2.7 Actividades de la implementación de la mejora Actividad Producto Elaborar material para capacitación Material de capacitación Realizar el piloto de los procesos y formatos definidos en cada proceso considerado Informe del piloto  Componente 5. Cierre del Proyecto. Este componente comprende la evaluación de los procesos final del ciclo de mejora previstos en la NTP-RT-ISO/IEC 29110:5-1-2:2012 (perfil Básico) y la ISO/IEC DTR 29110-5-1-3:2012 (perfil Intermedio). El detalle se puede observar en la Tabla 2.8. Tabla 2.8 Actividades del cierre Actividad Producto Elaborar el plan de evaluación de procesos Plan de Evaluación de procesos Elaborar del Informe de Evaluación de procesos Informe de Evaluación de procesos Elaborar Informes finales del Ciclo de Mejora Informe del Proyecto de Mejora de Procesos Realizar el cierre administrativo del Proyecto ---- Así mismo se adjunta en el Anexo 1 el cronograma que el proyecto siguió. 23 3 Marco de Referencia El marco de referencia presenta los conceptos relevantes para comprender el trabajo que se desarrolla. 3.1 Marco conceptual En el presente trabajo de fin de carrera se ha utilizado una serie de conceptos y términos asociados al tema desarrollado que si bien se dio una breve definición en la problemática, estos necesitan ser abordados con una mayor profundidad para que se pueda interiorizar mejor el tema. 3.1.1 Proceso Basado en lo establecido por la ISO 9001:2008, un proceso se define como el grupo de tareas o actividades relacionadas entre sí, las cuales necesitan de una serie de recursos con la finalidad de poder transformar los elementos de entrada en resultados [4]. 3.1.2 Calidad De acuerdo al glosario de términos propuesto por la ISO 9001:2008, calidad es el nivel en el cual un conjunto de características propias logran cumplir los requisitos solicitados. De manera similar, Crosby define calidad como la conformidad de requerimientos [27]. 3.1.3 Capacidad de proceso Según CMMI es el rango de resultados esperados que pueden lograrse siguiendo un proceso [6]. 3.1.4 Modelo Según la Real Academia de la Lengua Española (RAE) un modelo es un arquetipo o punto de referencia para imitarlo o reproducirlo [28], 3.1.5 Madurez de la organización Según CMMI, la madurez de la organización es el grado en el cual una organización ha desarrollado de forma explícita y consistente sus procesos que están documentados, gestionados, medidos, controlados y mejorados de forma continua [6]. 3.2 Modelos para proceso software Dentro de la ingeniería de software se encuentran tres grupos de modelos ampliamente usados en los procesos de software: Modelo de procesos, modelo de evaluación y modelo de mejora. Estos serán definidos en las siguientes líneas. 24 3.2.1 Modelo de procesos Un modelo de procesos brinda una serie de buenas prácticas para orientar una correcta estructuración de los procesos y sobre todo este modelo debe ser aplicable para la empresa. El propósito de éste es el de ser una guía para el diseño, análisis y la revisión de los procesos de software [11]. A continuación se detallará los marcos de referencias de mayor impacto en la industria del software: 3.2.1.1 ISO 9001:2008 La ISO 9001: Sistema de Gestión de la Calidad (ver Figura 3.1) es una norma o estándar establecido por la Organización Internacional para la Estandarización la cual presenta una serie de requisitos que tienen que ser cumplidos para llevar a cabo un sistema de gestión de calidad efectivo [4]. Al ser un estándar tan genérico permite que todo tipo de empresas pueda adaptar sus procesos a la norma para verificar si sus productos o servicios cumplen los requerimientos de calidad y por ende satisfacer a sus clientes. Entre los requisitos que se especifican se tienen los siguientes [4]:  La Organización debe mejorar la satisfacción del cliente mediante la aplicación eficaz del sistema de Gestión de Calidad, incluyendo procesos para la mejora continua del sistema y el aseguramiento de la conformidad de los clientes.  La Organización tiene que demostrar su capacidad para proporcionar de forma coherente productos que satisfagan a los clientes. 3.2.1.2 CMMI El Capability Maturity Model Integration (de ahora en adelante CMMI) es un conjunto de buenas prácticas establecidas por el SEI (Software Engineering Institute) basada en dos perspectivas: Continúa y Escalonada. El primero es de interés porque ofrece un reconocimiento y es el que se detalla a continuación. Este modelo permite identificar el nivel de capacidad que los procesos de una organización desarrolladora de software han alcanzado así como el nivel de madurez que una organización posee; y las pautas a seguir para la implantación de una estrategia de mejora continua [7]. Entre los beneficios que se generan por la aplicación de CMMI se pueden citar los siguientes [29]: 25 Figura 3.1 Sistema Gestión de Calidad [30]  Disminución de costos.  Mejora en entrega a tiempo.  Mejora de productividad.  Mejora en la calidad.  Mayor satisfacción del cliente.  Impresionante retorno de la inversión. Por otro lado, CMMI también presenta ciertas limitaciones que se detallan a continuación [29]:  Podría ser demasiado detallado.  Demanda muchos recursos para ser implantado totalmente.  Su interpretación puede ser prescriptiva. Como ya se mencionó anteriormente, CMMI evalúa el nivel de madurez de un conjunto de procesos y es por ello que en su estudio ha identificado cinco niveles en los cuales se puede encontrar un determinado proceso. Estos niveles se muestran en la Figura 3.2. 3.2.1.3 ISO/IEC 12207: Tecnologías de información/ Ciclo de vida del software Según Pino, “Esta norma presenta un modelo de procesos de referencia del ciclo de vida del software que son fundamentales para una buena ingeniería de software y cubre las mejores prácticas” [5]. 26 Figura 3.2 Niveles de madurez según CMMI. Adaptado de [24] Asimismo, esta norma detalla el conjunto de tareas y actividades que se deben realizar para implementar los procesos que permitirán adquirir las capacidades deseadas por los interesados (stakeholders), desarrolladores, proveedores, encargados del mantenimiento y operadores [31]. Dentro de este entorno de ciclo de vida del software cabe distinguir tres tipos de procesos: Principales, de apoyo y organizativos. Los principales son aquellos que dan servicio a los desarrolladores, operadores o encargados del mantenimiento; los de apoyo, aquellos que colaboran con el éxito y la calidad; y los organizativos, aquellos que contribuyen con la infraestructura y el personal respectivo al ciclo de vida [9]. La estructura de esta norma puede verse en la Figura3.3. 3.2.1.4 MoProsoft- Modelo de Procesos para la Industria de Software Según, Oktaba, MoProsoft es un modelo de software que tuvo su origen en México (Secretaria de Economía) y consiste básicamente en la integración tres sectores: Alta dirección, gestión y finalmente operaciones los cuales sintetizan una organización [23]. Optimizado Mejora del proceso Gestionado Cuantitativamente Proceso medido y controlado Definido Proceso proactivo y caracterizado por la organización Gestionado Proceso reactivo y caracterizado por proyectos Inicial Proceso poco predecible y controlado 27 Figura 3.3 Modelo de Proceso ISO/IEC 12207 [8] Así mismo, su adaptabilidad permite que pueda ser usado en empresas que no tengan aún sus procesos establecidos como en aquellas que solo necesiten incorporar algunos [32]. La estructura de este modelo puede verse en la Figura3.4. Según Oktaba se tienen las siguientes categorías [23]: “Alta Dirección: Categoría de procesos que aborda las prácticas de alta dirección relacionadas con la gestión del negocio. Proporciona los lineamientos a los procesos de la categoría de gerencia y se retroalimenta con la información generada por ellos. Gestión: Categoría de procesos que aborda las prácticas de gestión de procesos, proyectos y recursos en función de los lineamientos establecidos en la categoría de alta dirección. Proporciona los elementos para el funcionamiento de los procesos de la categoría de operación, recibe y evalúa la información generada por éstos y comunica los resultados a la categoría de alta dirección. Operaciones: Categoría de procesos que aborda las prácticas de los proyectos de desarrollo y mantenimiento de software. Esta categoría realiza las actividades de acuerdo a los elementos proporcionados por la categoría de gerencia y entrega a ésta la información y productos generados”. 28 El modelo MoProsoft está orientado hacia las medianas y pequeñas empresas desarrolladoras de software las cuales no califican en adaptación y aplicabilidad para seguir los lineamientos expuestos por CMMI o la ISO/IEC 15504 [33]. Es así que MoProsoft concentra todos sus esfuerzos en construir las mejores prácticas internacionales que sean fáciles de comprender y aplicar con un bajo costo en su adopción y sobre todo que estén a la medida o sean comparables con los modelos “top” pues facilita el cumplimiento de los requisitos de estos (ISO 9000:2000, CMM y CMMI). Su modelo se puede apreciar en la Figura 2.4. Figura 3.4 Modelo MoProsoft [29] 3.2.2 Modelo de mejora de procesos Un modelo de mejora de procesos es una base de referencia a partir de la cual se logra incrementar la calidad de los procesos con el fin de cubrir efectiva y eficazmente los requerimientos [4]. 3.2.2.1 IDEAL: IDEAL es un ciclo de mejoramiento de procesos, el cual comprende un conjunto de actividades propuestas por el SEI y que tienen como propósito la adopción de las buenas prácticas recomendadas por CMM (Modelo de Capacidad y Madurez) [34]. La aplicación de este modelo variará dependiendo del tamaño de la empresa, de sus operaciones (si se obtiene software externo o solo se realiza mantenimiento) y del tipo de industria de software (software de proceso de datos, en tiempo real, etc.). La recomendación que se debe seguir según Guerrero, es que al no tener detalles sobre la implementación, se debería solicitar ayuda externa experta para que oriente a la empresa desarrolladora de software a evaluar sus necesidades y a preparar un plan de acción [34]. 29 Las etapas del modelo IDEAL se muestran en la Figura 3.5. Figura 3.5 Etapas del modelo IDEAL. Adaptado de [30] 3.2.2.2 MPS.BR De acuerdo a lo que expone MPS.BR-2009, se trata de un modelo de mejora de procesos realizado en Brasil y a su vez presenta un método de evaluación de los procesos de software involucrados [35]. Esta guía está orientada a empresa micro, pequeñas y medianas y se ha basado en las normas ISO/IEC 12207 e ISO/IEC 15504 para la construcción de su modelo de procesos y evaluación [36]. MPS presenta una estructura que agrupa diferentes prácticas internacionales [35]. El modelo de mejora de procesos es conocido como MR-MPS; el método de evaluación, MA-MPS; y el modelo de negocio, MN-MP [35] (ver Figura 3.6). A diferencia de CMMI, este modelo distingue siete niveles de madurez [36]: A (optimización), B (Gestionado cuantitativamente), C (Definido), D (Ampliamente definido), E (Parcialmente definido), F (Gestionado), G (Parcialmente gestionado). Obviamente, el avance es de G hacia A y por cada escalón que se tiene se maneja un perfil de procesos el cual señala en donde se debe enfocar el esfuerzo de mejora. Así mismo, la razón de dividir el modelo en más niveles es porque esto permite visualizar los resultados de mejora en periodos de tiempo Inicia(Iniating) •Su propósito es establecer los fundamentos básicos para garantizar la iniciativa de mejoramiento de procesos. •Se aclaran con la gerencia cuales son los objetivos de la empresa u organizacion que serán beneficiados Diagnosticar (Diagnosing) •Su propósito es evaluar mediante un metodo formal las fortalezas y debilidades del proceso seguido por los proyectos. •Los objetivos del programa se relacionan con las prácticas existentes y se determinan aquellas que no están suficientemente desarolladas Establecer(Establishing) •Su propósito es realizar la planificación específica de los mejoramientos que se desea alcanzar. •Se desarrolla un plan detallado que sive como plan de proyecto. Actuar(Acting) •Elpropósito es simplemente implementar el mejoramiento de procesos l levando a cabo el plan de acción . •Aqui se introducen o mejoran los procesos, se entrena a los respectivos niveles de personal, se miden los avances/ beneficios logrado, se realizan proyectos pi loto, etc. Difundir(Leveraging) •El propósito es aprender de la experiencia del ciclo recién realizado y aumentar la habilidad de la empresa u organización para mejorar los procesos en forma continua. •Se determina los logros, el esfuerzo invertido. la manera en que las metas fueron sastisfechas y la forma más adelantada de implementar cambios en el futuro. 30 más cortos ya que, como se dijo anteriormente, uno de los tipos de empresa a las que se enfoca es la micro y estas, por lo general, buscan resultados de inmediato [37]. Figura 3.6 Componentes del Modelo MPS [31] 3.2.2.3 Agile SPI Este modelo fue desarrollado en Colombia y se caracteriza por pilotar la mejora de los procesos de software manteniendo un grado de agilidad deseado por la organización [38]. Así mismo, adecua otros principios para la gestión del desarrollo ágil y liviano; y además, es tan versátil que se adapta fácilmente a la cambiante e innovadora industria del software [39]. Para la mejora de procesos se debe determinar una serie de requerimientos mínimos y principios asociados a estos como los que se manifestarán a continuación [40]: R1: Ser efectivo y generar resultados exitosos R2: Ser incremental (se inicia con poco esfuerzo y luego se va extendiendo). R3: Proveer resultados rápidos y concretos R4: Utilizar TI existentes y probadas. 31 Así mismo, como se mencionó anteriormente, Agile SPI define una serie de principios para estos requisitos los cuales representan las bases en la gestión del proyecto [38]. P1: Satisfacer la necesidad del cliente. P2: El diagnóstico es una fase lave. P3: Entrega temprana de mejoras. P4: Reuniones cara a cara. P5: Individuos motivados. P6: Medición continua del proceso. P7: Mejora y aprendizaje continuos. P8: Infraestructura de trabajo para gestionar proyectos de SPI. P9: Minimizar la documentación. P10: Independencia del modelo de referencia a seguir. Por otro lado, cabe resaltar que Agile SPI está compuesta por cinco módulos en su diseño : Agile SPI Process (proceso ágil que dirige una mejora), Light SPI Evaluation Model (modelo de evaluación ligero del proceso productivo), Light SPI Metrics Quality Model (modelo ligero de métricas del proceso productivo), Framework PDS (marco conceptual y tecnológico para soportar procesos) y Light SPI Quality Model (Modelo de calidad ligero) [23]. 3.2.2.4 PmCompetisoft Este marco de referencia surge a partir de modelos anteriores como muchos de los modelos mencionados anteriormente. COMPETISOFT busca convertirse en un lenguaje universal que sea aplicable a todas las Pymes de Iberoamérica [41]. Para ello agrupa marcos que tuvieron éxito en sus respectivos países de origen (MoProsoft, MPS.BR y Mantema) y crea su respectivo modelo de procesos [42]. El objetivo general de este proyecto es “Incrementar el nivel de competitividad de las Pymes Iberoamericanas productoras de software mediante la creación y difusión de un marco metodológico común que, ajustado a sus necesidades específicas, pueda llegar a ser la base sobre la que establecer un mecanismo de evaluación y certificación de la industria del software reconocido en toda Iberoamérica” [41]. Para llevar a cabo este objetivo, el proyecto desmenuzó su objetivo principal en tres objetivos específicos que se detallan a continuación [42]:  Desarrollar un marco metodológico común ajustado a la realidad socio-económica de las Pymes iberoamericanas, orientado a la mejora continua de sus procesos. Este 32 marco metodológico está compuesto por un modelo de procesos, un método de evaluación y un modelo de mejora, el cual fue validado, en el marco de este proyecto, mediante su aplicación controlada en empresas y organizaciones de diferentes países de la región CYTED.  Difundir la cultura de la mejora de procesos en el sector informático iberoamericano y, más específicamente, formar tanto a investigadores y/o docentes universitarios (formación de formadores) como a profesionales de un buen número de Pymes productoras de software.  Incidir en los diferentes organismos de normalización y certificación de los países iberoamericanos, para que asuman que los principios metodológicos objeto de este proyecto CYTED pueden ser la base para establecer un mecanismo común y mutuamente reconocido de evaluación y certificación de la industria del software Iberoamericana. Como se visualiza en los objetivos específicos, COMPETISOFT busca un lenguaje común para todo Iberoamérica a través de la difusión de la mejora de procesos y mejor aún se encarga de especificar el marco metodológico común para las Pymes (pequeñas y medianas empresas) desarrolladoras de software [41]. Para su desarrollo se enriqueció de los modelos propuestos por MoProsoft (México), Agile SPI (Colombia) y Mantema (España). La estructura de este modelo puede apreciarse en la Figura 3.7 Figura 3.7 Modelo de procesos de COMPETISOFT [33] 33 3.2.3 Modelo de evaluación de procesos Los modelos de evaluación de procesos son utilizados para medir el nivel de progreso de los proyectos de software así como de los procesos que este comprende [12]. Gracias a este se puede evaluar el nivel de madurez que una empresa ha alcanzado hasta el momento. 3.2.3.1 ISO/IEC 15504: Conocida como tecnologías de la información: proceso de evaluación [5]. Es una norma establecida para el desarrollo de un modelo de evaluación de los procesos del ciclo de vida del software [43]. Esta ISO está organizada en dos partes, por un lado, la parte normativa (1, 2,7) la cual describe los requisitos mínimos a contar para poder realizar la mejora de los procesos de desarrollo y para poder determinar el grado de madurez alcanzado durante y después del proceso de mejora; y por otro lado, la parte no normativa (3, 4, 5 ,6) en donde se detalla e interpreta mejor los requisitos y la norma en sí [43]. En la Figura 3.8 se puede apreciar con mejor claridad la estructura de la norma. La parte 7 específica y ahonda más en cuanto a los requisitos mínimos que se deben considerar para realizar la evaluación de los procesos del ciclo de vida del software con el fin de determinar el nivel de madurez. Estos niveles se ejemplifican mejor en la Figura 3.9. Esta es bastante económica y se puede ajustar a las distintas exigencias y a la forma de trabajo de cada empresa [43]. Por otro lado, no siempre resulta conveniente aplicarla en pequeñas empresas con equipos de trabajo menores a 20 personas; esto por temas de costo y disponibilidad de recursos humanos. 3.2.3.2 SCAMPI: (Standard CMMI Appraisal Method for Process Improvement) Es un método de evaluación que se utiliza para medir el grado de madurez que obtuvo una empresa que ha empleado como modelo de referencia CMMI [12]. Como fin principal contempla la identificación de fortalezas y oportunidades de mejora de procesos a partir del empleo de las buenas prácticas seguidas previamente en el modelo adoptado (como ya se mencionó, CMMI). 34 . Figura 3.8 Estructura de la ISO 15504 [34] Figura 3.9 Niveles de Madurez de la parte7 [34] Cabe resaltar, que este es solo un método mas no una certificación ya que el Software Engineering Institute no ha establecido un mecanismo de seguimiento de los resultados, solo los considera hasta un plazo de tres años. Dentro de sus funciones principales se pueden citar las siguientes [12]:  Analizar  Motivar 35  Transformar  Educar Así mismo, el empleo de este método genera ciertos beneficios dignos de destacar [12].  Mejor visibilidad de proyecto: Los miembros son conscientes de sus actividades y la Dirección conoce la fase de sus proyectos.  Mejor comunicación: Los involucrados conocen sus compromisos y tareas.  Planes de proyectos más realistas: Se evalúa lo que la organización la aptitud de la empresa y en base a ello se procede.  Disminuye el re-trabajo: La detección de errores es más anticipada.  La organización se conoce más a si misma: La empresa conoce sus limitaciones. 3.2.3.3 EvalProsoft Este método de evaluación se basa en la ISO/ IEC 15504 y también está dirigida a pequeñas y medianas empresas desarrolladoras de software. EvalProsoft es el método usado por excelencia por aquellas empresas que tomaron como marco de referencia a MoProsoft [44]. Este método se puede emplear de tres maneras distintas: La evaluación de la – acreditación de capacidades, la evaluación de las capacidades de los proveedores y la autoevaluación de las capacidades del proceso [10]. El primer tipo de evaluación se usa cuando la empresa requiere de un evaluador certificado para valorar el grado de madurez de la compañía y la capacidad de sus procesos con el fin de tomar acciones de mejora. El segundo tipo se manipula cuando la organización quiere ser más selectiva con sus proveedores y evalúa los procesos de desarrollo y mantenimiento que estos realizan. Por último, el tercer tipo es usado para generar un input para llevar a cabo un plan de mejora y para ello tasa al personal de la organización. Por otro lado, EvalProsoft mide la capacidad de los procesos a partir de una serie de atributos que se establece por proceso. Estos se especifican con mayor detalle en la Figura 3.10. 36 Figura 3.10 Niveles de capacidad [23] 3.3 Experiencias de mejora En éste apartado se puntualizarán casos de pequeñas organizaciones desarrolladoras de software que decidieron ejecutar ciclos de mejora en sus procesos y los resultados que éstas obtuvieron a manera de tendencia. Así mismo se detallarán las causas que hicieron posible el éxito o fracaso y los problemas que se les cruzaron en el camino hacia esa mejora. 3.3.1 Tesis de Competisoft-Perú Las tesis de pregrado desarrolladas dentro del proyecto COMPETISOFT tuvieron como objetivo principal ejecutar un ciclo de mejora en una pequeña empresa que desarrolla software [45]. Gracias al levantamiento de información, los estudiantes pudieron detectar los problemas principales que afectaban el correcto desempeño de las organizaciones. Como por ejemplo, insatisfacción del producto final entregado, imprecisa estimación de la duración de los proyectos, falta de planeamiento, entre otros [46] [47]. A partir de estos problemas junto con los objetivos del negocio y los procesos, los estudiantes, con asesoría de los responsables del proyecto, pudieron seleccionar los procesos sobre los cuales se ejecutaría el ciclo de mejora. Los resultados obtenidos, en general, fueron exitosos así lo evidencian los documentos de tesis. Sin embargo, muchos de ellos expresan que aún se pudieron obtener mejores resultados si hubiese habido mayor uniformidad en la participación de los responsables, un mayor horizonte de tiempo, menor multifuncionalidad de roles entre otras cuestiones [48] [49]. 37 3.3.2 Experiencias de MoProsoft Como se mencionó anteriormente, el modelo MoProsoft fue desarrollado en México como un intento por mejorar los procesos de las empresas que desarrollaban software (en México el 99% de las empresas son Pymes) [23]. Al término de la implantación del modelo en empresas piloto de este rubro –desarrollo de software- se obtuvieron resultados significativos [50]. Las empresas elevaron considerablemente la capacidad de sus procesos y se pudo corroborar la efectiva aplicación del modelo MoProsoft a empresas pequeñas [51]. Por otro lado, durante su implantación se pudo detectar que aún hay resistencia al cambio, falta de compromiso por parte de la alta dirección y falta de cultura de procesos como parte de los principales obstáculos [52]. De esta experiencia se pudo determinar que la gestión de procesos es de vital importancia porque todo parte de la correcta definición de los procesos, si éstos no están bien definidos previamente no se puede determinar qué parte del flujo procedural mejorar [51]. Sin embargo, también es crucial instaurar planeamiento estratégico para que a través de este se pueda orientar la mejora al cumplimiento de los objetivos del negocio [52]. 3.3.3 Problemas en mejora de procesos en Pymes Durante el proceso de implantación de las mejoras surgen diferentes tipos de obstáculos con las cuales se tiene que lidiar si es que se quiere tener éxito en el ciclo de mejora. Uno de estos obstáculos percibidos ha sido la ambigüedad que presentan los modelos ya que estos son solo un conjunto de buenas prácticas que no especifican cómo realizar su implantación [53]. Asimismo, se ha detectado que las pequeñas empresas no perciben el control de versiones como objeto que genera valor sino como una carga extra; puesto que, muchas de estas trabajan perfectamente sin el uso de ninguna herramienta de control de versiones y, por ende, no consideran que sea útil si llegaran a crecer un poco más [53]. Otro problema encontrado durante la implantación de buenas prácticas ha sido que las empresas con experiencias previas en mejora de procesos consideran que la introducción de revisiones técnicas es una sobrecarga de trabajo y genera un sobrecoste inasumible [53]. Finalmente, la gestión de proyectos se deja de lado y los involucrados se concentran con mayor dedicación en la parte técnica. En ese sentido el esfuerzo y costo planificado para el proyecto no se llega a cumplir en la mayoría de los casos [53]. Asimismo, la inadecuada gestión de los proyectos conlleva al retraso de estos y, como consecuencia, las actividades de verificación y validación son reducidas para cubrir las de implementación (impacto negativo en la imagen de la empresa) [26]. 38 3.4 INGENIERIA DE SOFTWARE. Perfiles del ciclo de vida para las pequeñas organizaciones (PO). La industria del software es consciente del aporte valioso que las micro, pequeñas y medianas organizaciones ofrecen al mercado; y en reconocimiento a este desempeño, la organización internacional de estandarización (ISO) ha establecido una norma para que estas organizaciones alineen sus procesos con prácticas reconocidas internacionalmente (ISO/IEC 29110). 3.4.1 Estructura de la Norma La norma ISO/IEC 29110 está dividida en tres apartados: Visión general, perfiles y guías. Así mismo esta norma fue desarrollada pensando en las pequeñas organizaciones que no se pueden adaptar fácilmente a las normas internacionales de calidad del software por las razones ya explicadas en el capítulo uno. Se puede apreciar esta estructura de manera detallada en la Figura 3.11.  Visión General (RT 29110-1) Este apartado contiene todos los conceptos fundamentales para entender la norma. Asimismo, informa cómo usar los diferentes documentos que administra [54].  Perfiles Los perfiles contienen referencias a otros documentos formales con el fin de adaptarlos a las pequeñas organizaciones. Para producir un perfil, se requiere de dos documentos previos: El marco de referencia y taxonomía y las especificaciones de cada perfil, 1. Marco de referencia y taxonomía( 29110-2) Detalla los componentes comunes existentes en los perfiles y adiciona un catálogo o jerarquía entre estos (Básico, Intermedio y Avanzado) [54]. 2. Especificaciones de perfil ( 29110-4) Como su nombre lo dice, este documento contiene todo el detalle definitivo por perfil. Asimismo, los enlaces normativos al subconjunto normativo de estándares y los enlaces informativos a documentos de entrada [54]. 39  Guías Comprenden todas las reglas de aplicación sobre cómo realizar los procesos y las evaluaciones de estos para, de esta manera, alcanzar los niveles de madurez deseados por la organización (plantillas, modelos, formatos, etc.). 1. Guías de evaluación ( 29110-3) Detalla el conjunto de pasos a realizar para llevar a cabo una evaluación efectiva y con ella determinar las capacidades de los procesos así como la madurez organizacional [54]. 2. Guías de ingeniería de gestión ( 29110-5) Informan sobre el procedimiento que se debe realizar para ejecutar la implementación y sobre el uso adecuado del perfil en el que se encuentra [54]. Figura 3.11 Estructura de la norma ISO/IEC 29110 [54] 3.4.2 VSE Perfil Básico El marco del Perfil Básico para las pequeñas organizaciones (very small entities o VSE) es una guía de gestión e ingeniería basada en la norma ISO/IEC 29110-5-1-2 donde se 40 detalla cómo debe ser el desarrollo de software en un determinado proyecto interno o externo a la organización [16]. Esta guía está orientada solo a pequeñas organizaciones (PO) y para aplicarla se necesita contar con ciertas entradas:  La declaración del trabajo debe estar documentada.  La viabilidad del proyecto debe ser realizada antes de su inicio.  El equipo del proyecto, incluyendo el administrador, deben estar asignados y entrenados.  Se debe disponer de los bienes, servicios e infraestructura necesarios. En el perfil básico se encuentran dos procesos: Administración del proyecto y la implementación de software [16]. El primero tiene como objetivo realizar las tareas de implementación metódicamente mientras que el segundo se preocupa por las actividades de análisis, diseño, construcción, integración y pruebas del producto software. La estructura de este perfil se detalla en la Figura 3.12. Figura 3.12 Procesos del perfil básico VSE [16] 3.4.3 Perfil Organizacional El perfil organizacional o perfil intermedio está basado en el estándar ISO/IEC 29110-1-3 y su propósito es ser una guía o conjunto de buenas prácticas (integra también prácticas de la ISO/IEC 12207) para que las pequeñas organizaciones establezcan procesos que implementen cualquier aproximación o metodología de desarrollo. Así mismo, este perfil tiene como público objetivo a aquellas pequeñas empresas que ya han incorporado el perfil básico a su modelo de trabajo [16]. 41 Por otro lado, esta guía proporciona gestión y prácticas de ingeniería a través de tres procesos Gestión de recursos, gestión de procesos y la gestión del portafolio de proyectos. El primer proceso se enfoca en la obtención y provisión de los recursos necesarios (materiales y humanos) para que la organización trabaje eficientemente. El segundo, se centra en el establecimiento y la mejora de los procesos que gestiona la organización. Finalmente, el último se encarga de la generación de proyectos, el otorgamiento del contenido técnico para el acuerdo formal de cada proyecto y la supervisión del desempeño total. Además, este último proceso siempre se encuentra monitoreando la satisfacción del cliente en todo momento [16]. 42 4 Mejora del Proceso Para el presente trabajo de fin de carrera, como se mencionó anteriormente, se trabajó sobre una pequeña organización dedicada al desarrollo de software. Esta ha sido referenciada a lo largo de todo el documento bajo la etiqueta de LIM.DELTA debido a que el tesista (por parte del proyecto ProCal-ProSer) firmó un contrato de confidencialidad con la empresa en estudio a fin de respetar la no divulgación de información comprometedora que pudiese tener algún impacto negativo en ella 4.1 Descripción de la Empresa LIM.DELTA fue fundada en el Perú en 1991 con la finalidad de brindar soluciones automatizadas que mejoren el nivel de competitividad de sus clientes. Para ello, la pequeña organización (PO) se basa en las estrategias de reducción de costos, incremento de la productividad y mejora del servicio que sus clientes ofrecen. LIM.DELTA se caracteriza principalmente por mantenerse a la vanguardia de la tecnología y, es por ello, que se ha convertido en una de las empresas pioneras en incorporar tecnología especializada en el Perú. Así mismo, esta organización con el tiempo, comenzó a prosperar y evolucionar, logrando expandirse internacionalmente en el año 2005. En la actualidad, la compañía mantiene su oficina central en Lima – Perú, pero cuenta, además, con una red de 2 filiales (EEUU y Colombia). LIM.DELTA es una empresa que se ha especializado en el desarrollo de soluciones con tecnología especializada, impresión especializada, soluciones móviles y redes inalámbricas. Organizacionalmente, la empresa cuenta con un staff técnico certificado a nivel internacional por sus socios de negocio: Motorola y Zebra Technologies. Estos factores le han otorgado un reconocimiento como líder en automatización a nivel Latinoamericano. En la actualidad, LIM.DELTA administra 110 trabajadores a nivel organizacional. Sin embargo el área de sistemas, compuesta por sub-áreas (Desarrollo y Calidad), está conformada por 15 personas. La primera sub-área consta de 9 personas (5 desarrolladores, 2 analistas programadores y 2 analistas funcionales) y la segunda está compuesta por 6 personas (3 implantadores, 2 testers y 1 jefe de calidad). Por otro lado, LIM.DELTA compite principalmente con 4 comercializadores de soluciones con tecnología especializada los cuales han demostrado gran persistencia y permanencia en el tiempo. A continuación, se detallará el organigrama de la empresa en la figura 4.1 para comprender mejor su estructura. 43 4.2 Evaluación diagnóstica de la empresa De acuerdo al plan de trabajo establecido y como parte de la implantación de la norma ISO/IEC 29110, se procedió a realizar una evaluación inicial de tipo ligera (sin exigencia de evidencias) de los procesos actuales de la empresa. El modelo utilizado para realizar esta evaluación fue el de la ISO/IEC 15504, el cual considera las siguientes escalas: No alcanzado-N (0%-15%), parcialmente alcanzado-P (16%-50%), ampliamente alcanzado-L (51%-85%) y completamente alcanzado-F (86%-100%) [10]. Cabe resaltar que los rangos establecidos en porcentajes por escala no son propios del modelo, pero para fines del proyecto se han delimitado de esa manera. Esto con la finalidad de que la empresa tenga un bosquejo de su estado inicial y pueda discernir qué tan próxima se encuentra para cumplir con los lineamientos del estándar. Por otro lado, el procedimiento ejecutado para el despliegue de la evaluación fue a través de entrevistas, previa coordinación con el Jefe de proyectos. 4.2.1 Propósito de la evaluación El propósito de esta evaluación fue poder determinar el perfil de capacidades de la organización así como el alcance que tuvo el proyecto a partir del plan de mejora de procesos basado en la ISO/IEC 29110. 4.2.2 Objetivos de negocio Por otro lado, como parte de la inducción realizada en la empresa, se recopilaron los objetivos de negocio que LIM.DELTA persigue en la actualidad. Estos objetivos, en un inicio, no estaban documentados ni establecidos de manera formal sino que tuvieron que obtenerse a partir de reuniones con personal administrativo que tenía poder de decisión. Los objetivos de negocio que finalmente se definieron fueron los siguientes:  Actualización de la oferta de soluciones y desarrollo de nuevas aplicaciones.  Posicionar la marca de la empresa como estrategia de llegada a los mercados externos.  Mejorar la atención post venta al cliente.  Implementar la Norma ISO 29110 para desarrollo de software.  Explorar mercados externos a través de la alianza con distribuidores en países como: Panamá, México, Chile, Colombia. 4.2.3 Procesos evaluados Así mismo, durante la evaluación diagnóstica realizada en LIM.DELTA, se consideraron 5 procesos del modelo ISO/IEC 29110 para ser examinados. 44 Figura 4.1 Organigrama de LIM.DELTA Estos procesos fueron los siguientes: Del perfil básico:  Gestión de proyecto (PM)  Implementación de software (SI) Del perfil intermedio:  Gestión del portafolio de proyectos (PPM)  Gestión de recursos (RM)  Gestión de procesos (PSM)  El plan de evaluación inicial que se siguió para el proyecto puede verse en el ANEXO 2. 4.2.4 Perfil de capacidades Una vez terminada la evaluación inicial, se lograron obtener el perfil de capacidades y el grado de cumplimiento de la organización LIM.DELTA respecto a la norma ISO/IEC 29110. Los cuales forman parte del resultado esperado número uno. En la Tabla 4.1 se puede visualizar el porcentaje de cumplimiento de cada proceso y el indicador del grado de cumplimiento que indica el nivel alcanzado (esta nomenclatura ya se explicó en líneas 45 anteriores). Asimismo, la Figura 4.2 explica la situación inicial del nivel o perfil de capacidad de los procesos ejecutados en la organización. Tabla 4.1 Porcentaje de cumplimiento por proceso evaluado P R O C E S O S PM SI RM PSM PPM % cumplimiento 47.1 57.5 44.7 0.0 28.3 Grado de cumplimiento P L P N P Nivel 0 0 0 0 0 Figura 4.2 Perfil de capacidades Según los resultados obtenidos de la evaluación diagnóstica, el 100% de los procesos evaluados no alcanzó el nivel de cumplimiento mínimo requerido. Lo que equivale a decir, ninguno de los 5 procesos evaluados se encuentra en el nivel de capacidad 1- Proceso Cumplido. Esto debido a que ningún proceso pudo ser capaz de superar el 85% de realización o cumplimiento de las actividades involucradas para cada proceso de acuerdo al modelo de evaluación ISO/IEC 15504. 4.2.5 Resultado obtenidos Asimismo, al terminar de realizar la evaluación se logró identificar el estado actual del área de sistemas a través de sus fortalezas y oportunidades de los procesos evaluados. A partir de este análisis junto con la priorización de procesos se elaboró el plan de mejora, el cual será detallado en la siguiente sección. Por el momento, se detallarán el perfil de capacidades y el análisis de fortalezas y oportunidades de mejora. El detalle completo de los resultados de la evaluación inicial puede verse en el ANEXO 3. 100.0% 47.1% 57.5% 44.7% 0.0% 28.3% 0.00% 50.00% 100.00% 150.00% Referencia PM SI RM PSM PPM Perfil de capacidades 46 A. Gestión de Proyecto El objetivo de este proceso es establecer y llevar a cabo las tareas del proyecto de implementación de software de manera sistemática para poder cumplir con los objetivos del proyecto en presupuesto, tiempo y calidad. De acuerdo a la evaluación, el porcentaje de cumplimiento de este proceso fue de 47.1 y el gráfico de la Figura 4.3 detalla la distribución de las calificaciones de las respuestas vertidas en la entrevista. Como consecuencia de la entrevista, se identificaron las siguientes fortalezas y oportunidades de mejora en el proceso de gestión de proyecto: Fortalezas:  Realizan de planificación de proyecto.  Establecen acuerdos de entregables con el cliente.  Trabajan en conjunto con el cliente: Reuniones para absolver dudas.  Inician el proyecto con la firma de aprobación de los requerimientos.  Realizan la formalización del cierre del proyecto con el cliente.  Desempeñan roles múltiples para realizar propuestas técnicas económicas. Esta puede ser hecha por el Gerente comercial o escalarla al Jefe de proyectos.  Gestionan sus recursos adecuadamente.  Realizan reuniones, casi diarias, de equipo para resolver problemas y revisar avances. Figura 4.3 Distribución de puntuación de la Gestión de Proyecto 15% 31% 27% 27% Gestión de Proyecto N P L F 47 Oportunidades de mejora:  Gestionar los riesgos de cada proyecto.  Manejar indicadores de gestión de proyectos.  Cumplir con los plazos fijados inicialmente con el cliente.  Realizar copias de bajo una estrategia. No solo al finalizar el proyecto  Administrar más recursos humanos.  Gestionar la configuración del desarrollo del proyecto.  Entregar mayor tiempo para realizar y ejecutar los casos de prueba.  Asignar mayor tiempo para realizar las correcciones de las pruebas con el fin de lograr levantar todas las observaciones.  No fiarse en que habrán retrasos en las actividades del cliente ni que habrá toda una semana de evaluación de prueba del producto, que por lo general la otorga el cliente, para levantar todas las observaciones registradas por el área de calidad. B. Implementación de Software El propósito del proceso de implementación de software es desempeñar sistemáticamente el análisis, diseño, construcción, integración y actividades de prueba para nuevos productos software o modificaciones en este de acuerdo a los requerimientos del cliente. Figura 4.4 Distribución de puntuaciones de Implementación de Software De acuerdo a la evaluación, el porcentaje de cumplimiento de este proceso fue de 57.5 y el gráfico de la Figura 4.4 se detalla la distribución de las calificaciones de las respuestas vertidas en la entrevista. 22% 15% 20% 43% Implementación de Software N P L F 48 Como consecuencia de la entrevista, se identificaron las siguientes fortalezas y oportunidades de mejora en el proceso de gestión de proyecto: Fortalezas  Cuentan con un área de calidad específica para realizar las pruebas necesarias de sus productos.  Se asignan recursos de acuerdo a la especialización de cada miembro. Por ejemplo, un analista que se ha especializo en el producto XXX realiza el análisis para un producto del mismo tipo pero con variaciones solicitadas en base a las necesidades del cliente.  Realizan un acta de confirmación de los requisitos antes de iniciar el desarrollo  Realizan revisiones de los casos de prueba que los testers elaboran antes de ser ejecutados.  Documentan los casos de prueba junto con los resultados de la ejecución (incidencias, criticidad y solución).  Documentan sus manuales de instalación y estos son revisados por el jefe de calidad.  Realizan la entrega del producto o servicio de acuerdo a las instrucciones pactadas inicialmente. Oportunidades de mejora:  Realizar los requisitos a alto nivel dentro de la propuesta técnica- económica para luego definir otro documento que contenga el catálogo de requisitos donde se precise el detalle de estos.  Procurar obtener los requisitos por parte de los usuarios finales del cliente. Ya que el no hacerlo ha originado, en algunos casos, que el producto final no sea el esperado.  Registrar la trazabilidad del desarrollo para identificar dependencias y posibles retrasos.  Monitorear y controlar de mejor manera el avance de los desarrolladores ya que, durante las pruebas, siempre se levantan observaciones de criticidad uno. Este tipo de observaciones no deberían surgir ya que demostraría ineficacia en la labor de los desarrolladores por un inadecuado seguimiento de estos.  Documentar los casos de prueba unitarios que cada desarrollador realiza.  Documentar y revisar el mantenimiento que se realiza para llevar un mejor registro de los productos y/o actualizaciones comprados por el cliente. Esta 49 documentación será de gran ayuda cuando surja algún tipo de reclamo por defectos en el software. C. Gestión del Portafolio de Proyectos El propósito de la gestión del portafolio de proyectos es generar proyectos para la organización, proveer contenido técnico para establecer acuerdos formales de los proyectos y supervisar su rendimiento a través del constante monitoreo de la satisfacción del cliente. Figura 4.5 Distribución de puntuación del Portafolio de Proyectos De acuerdo a la evaluación, el porcentaje de cumplimiento de este proceso fue de 28.3 y el gráfico de la Figura 4.5 detalla la distribución de las calificaciones de las respuestas vertidas en la entrevista. Como consecuencia de la entrevista, se identificaron las siguientes fortalezas y oportunidades de mejora en el proceso de gestión de proyecto: Fortalezas:  Incrementan el número de los recursos cuando se tienen proyectos retrasados.  Realizan una preparación y programación de los proyectos de acuerdo a las órdenes de venta recibidas.  Cuentan con personal capacitado en la gestión de proyectos. 27% 40% 20% 13% Portafolio de Proyectos N P L F 50 Oportunidades de mejora:  Clasificar sus proyectos.  Realizar planeamiento estratégico  Todos los controles que se realizan debido a cambios o desviaciones deben estar basados, en primer lugar, en las necesidades del negocio y luego en otras variables como el tiempo. D. Gestión de Recursos El propósito del proceso de gestión de recursos es obtener y proveer a la organización con los recursos que necesita. Figura 4.6 Distribución de puntuación de Gestión de Recursos De acuerdo a la evaluación, el porcentaje de cumplimiento de este proceso fue de 44.7 y el gráfico de la figura 4.6 detalla con mayor precisión la distribución de las calificaciones de las respuestas vertidas en la entrevista. Como consecuencia de la entrevista, se identificaron las siguientes fortalezas y oportunidades de mejora en el proceso de gestión de proyecto: Fortalezas:  Cuentan con un encargado en el área de sistemas que les proporciona los recursos materiales para el desarrollo del producto (computadoras, herramientas, etc.). Así mismo, hay un grupo, en el área de almacén, que les facilita otro tipo de hardware (lectoras de código de barras, RFID, etc.). 16% 31% 32% 21% Gestión de Recursos N P L F 51  Realizan pruebas de evaluación de su personal cada año para medir su rendimiento.  Actualizan los CV’s de los trabajadores conforme a las capacitaciones que estos reciben en el año.  Actualmente, cuentan con Pc’s extras porque su equipo de desarrollo se ha reducido.  La gerencia de finanzas evalúa el costo-beneficio de todos los requerimientos de recursos. Oportunidades de mejora:  Se deberían dar a conocer las políticas de recursos humanos en la empresa.  Incorporar por lo menos a una persona más en el área de recursos humanos.  Difundir las políticas y los objetivos de negocio de la organización en todas las áreas.  Se debe realizar mantenimiento preventivo de los equipos con los que trabaja el área de desarrollo y calidad. Ya que el riesgo de que se deterioren los equipos por el uso cotidiano es alto.  Se deben realizar con mayor frecuencia capacitaciones en el área de desarrollo. Últimamente no las han estado recibiendo.  Se debe tener un encargado del grupo de almacén que se enfoque principalmente en la concesión de equipos de hardware cuando el área de desarrollo lo solicite. Ya que la falta de atención a estos requisitos origina retrasos en los proyectos. E. Gestión de Procesos El propósito del proceso de gestión de procesos es establecer y mejorar los procesos organizacionales. De acuerdo a la evaluación, el porcentaje de cumplimiento de este proceso fue de 0.0 y el gráfico de la Figura 4.7 detalla con mayor precisión la distribución de las calificaciones de las respuestas vertidas en la entrevista. Claramente se puede apreciar que el 76% de este proceso no se realiza en LIM.DELTA y apenas el 24% del proceso es practicado pero muy pobremente. 52 Figura 4.7 Distribución de puntuación de Gestión de Procesos Como consecuencia de la entrevista, se identificaron las siguientes fortalezas y oportunidades de mejora en el proceso de gestión de proyecto: Oportunidades de mejora:  Se debe establecer y actualizar un plan de procesos.  Se debe evidenciar la revisión de los procesos.  Se debe evidenciar el seguimiento sobre la ejecución del plan de procesos y la identificación de ajustes.  Se debe evidenciar el establecimiento o generación del repositorio organizacional.  Se debe evidenciar la inclusión del repositorio de cada proyecto cerrado en el Repositorio Organizacional.  Se debe evidenciar la generación de la copia de seguridad del repositorio de la organización según la Estrategia de repositorio organizacional.  Se debe evidenciar el establecimiento o actualización del mapa de procesos.  Se debe evidenciar la revisión del mapa de procesos.  Se debe evidenciar la identificación de buenas prácticas o experiencias para la mejora de los procesos.  Se debe evidenciar la revisión de la documentación de procesos.  Se debe evidenciar la integración o actualización sobre la definición de procesos.  Se debe evidenciar el entrenamiento a la organización sobre los procesos definidos.  Se debe evidenciar la actualización del repositorio organización con la definición de los procesos.  Se debe evidenciar el despliegue de los procesos definidos y el plan de procesos.  Se debe evidenciar la determinación de las fechas de evaluación, el alcance y los roles responsables. 76% 24% 0% 0% Gestión de Procesos N P L F 53  Se debe evidenciar la ejecución de las evaluaciones de procesos organizacionales.  Se debe evidenciar la revisión de los reportes de evaluación de procesos.  Se debe evidenciar la actualización de los registros de evaluación de procesos.  Se debe evidenciar el análisis de las fortalezas y debilidades, e identificación de las mejoras a los procesos.  Se debe evidenciar la recopilación de sugerencias de mejora realizadas por VSE.  Se debe evidenciar la recopilación de sugerencias de mejora realizadas por PO.  Se debe evidenciar el análisis, selección y priorización de mejoras de procesos.  Se debe evidenciar la información periódica sobre el estado de los procesos (plan, evaluaciones, registros, mejoras, documentación).  Se debe tener registros que evidencien la obtención de sugerencias de mejora de procesos para este proceso. 4.2.1 Esquema de trabajo del proyecto El despliegue del proyecto ProCal-ProSer está basado en la realización de 5 grandes actividades, según la norma ISO/IEC 29110: Diagnóstico, formulación, instalación, ejecución y revisión.  Diagnóstico de procesos Como ya se mencionó anteriormente, en la etapa inicial del proyecto se realizó una evaluación diagnóstica para determinar el grado de adhesión de los procesos actuales de la empresa a los del modelo y, con ello, determinar el alcance de la propuesta de mejora.  Formulación de mejoras En base a los formatos que el proyecto brinda, apoyado en la norma, se definió una estrategia de mejora. Esta consistió en formular casos de mejora probando la incorporación de nuevas actividades, modificación de algunas actividades y la agregación de nuevas herramientas. Previamente a esto, el tesista con los responsables del proyecto conversaron sobre que procesos sería más factible ejecutar el ciclo de mejora. 54  Instalación del ciclo En esta etapa se presentó la propuesta de mejora formulada anteriormente y se realizaron ajustes de acuerdo a las exigencias del jefe de proyectos y de la gerencia. Cabe resaltar, que esta propuesta fue elaborada en base a la priorización de procesos (según estas variables: Objetivos de negocio, procesos y problemas) que se detallarán en el siguiente capítulo.  Ejecución de mejoras Una vez aprobada la propuesta de mejora, se seleccionaron dos proyectos pilotos para aplicar los casos de mejora. Durante esta actividad, se tuvieron que afinar ajustes para armonizar la forma de trabajo de la empresa con la propuesta.  Revisión del ciclo Finalmente, se volvió a aplicar la prueba diagnóstica sobre los proyectos piloto para evaluar si la empresa era capaz de ejecutar sus procesos en base al estándar ISO/IEC 29110. Para esta actividad se exigió evidencia contundente que acredite la veracidad de las entrevistas. 4.3 Plan de mejora de procesos Luego de realizar la inducción, la evaluación diagnóstica y el análisis de la situación actual de la empresa respecto a sus procesos, se realizó también la propuesta de mejora en base a los resultados obtenidos de las actividades mencionadas anteriormente. Con esta propuesta, se logró ejecutar el primer ciclo de mejora en LIM.DELTA y se volvieron a evaluar los procesos ya descritos anteriormente para medir el progreso de su capacidad. Cabe resaltar que la propuesta de mejora brindada a la empresa tuvo que estar ajustada a la forma como la organización realiza sus actividades ya que la idea era que la mejora fuera realmente una ayuda y no una carga para los participantes de los diferentes procesos. En ese sentido, para el planteamiento de la mejora tuvo que recurrirse también al modelo de COMPETISOFT. Este apartado está dividido en dos partes. La primera consiste en mostrar el método de priorización llevado a cabo en LIM.DELTA para obtener buenas aproximaciones de los procesos que deberían tener mayor relevancia al momento de elaborar la propuesta de mejora. La segunda parte se enfoca en la propuesta propiamente dicha. Dentro de ésta, se detallan el diseño de los procesos, el orden de priorización de los procesos que se 55 mejoraron, la situación actual de LIM.DELTA, en ese entonces, y la situación de mejora que se deseaba alcanzar para el proyecto de fin de carrera. El detalle del plan de mejora así como las acciones de mejora pueden visualizarse a su cabalidad en los ANEXOS 4 y 5. 4.3.1 Priorización de procesos Este método consiste en asignar una puntuación (4= Alto, 2=Medio y 1=Bajo) dependiendo de la percepción que se tenga del impacto de un elemento (problemas de negocio o procesos) sobre otro (objetivos de negocio o problemas de negocio) según sea el caso. Así mismo, para el cálculo se requirió calcular el peso para cada elemento (objetivo de negocio, problemas de negocio y procesos). Con la integración de éstos cálculos fue posible establecer qué procesos mejorar y en qué orden. A continuación se detalla la priorización de procesos realizada para cada caso. A. Objetivos de negocio vs. Problemas de negocio Para llevar a cabo esta priorización fue necesario identificar los objetivos de negocio de LIM.DELTA. Este proceso, como se mencionó anteriormente, tomó cierto tiempo; puesto que, la empresa no contaba con un planeamiento estratégico formal. Con la ayuda de personal administrativo, el jefe Proyectos y el tesista se pudo obtener la aprobación de la Gerencia sobre los objetivos de negocio que este equipo planteó. Luego de ello, el tesista a través de entrevistas con el jefe de Proyectos y con personal de Gerencia logró detectar los principales problemas que el área de sistemas (Desarrollo y Calidad) de LIM.DELTA presentaba. En la tabla 4.4 se observa las calificaciones que se obtuvieron al realizar este primer cruce (objetivos de negocio y problemas de negocio). El peso que la gerencia determinó para sus objetivos de negocio se muestra en la tabla 4.2. Así mismo, la Gerencia, en base, a la experiencia del negocio, determinó los pesos para los problemas que el tesista identificó (ver tabla 4.3). Finalmente, con ayuda de estos pesos se pudo completar el cálculo del factor de relevancia o impacto de cada uno de los problemas en los objetivos que persigue LIM.DELTA. La fórmula para hallar ese factor es la siguiente: 𝑃𝑒𝑠𝑜𝑃𝑟𝑜𝑏𝑙𝑒𝑚𝑎𝑁𝑒𝑔𝑜𝑐𝑖𝑜 ∗ (∑𝑃𝑒𝑠𝑜𝑂𝑏𝑗𝑒𝑡𝑖𝑣𝑜𝑁𝑒𝑔𝑜𝑐𝑖𝑜 ∗ 𝐶𝑎𝑙𝑖𝑓𝑖𝑐𝑎𝑐𝑖ó𝑛𝐴𝑠𝑖𝑔𝑛𝑎𝑑𝑎) 56 Tabla 4.2 Pesos asignados a los objetivos de negocio Tabla 4.3 Peso de los problemas de negocio B. Problemas de negocio vs. Procesos Para llevar a cabo esta priorización se necesitó del cálculo del factor de relevancia de cada problema. Este ya fue determinado en la sección A del presente apartado y fue utilizado como peso del problema en esta priorización. Así mismo, de acuerdo al número de procesos considerados, se distribuyó un porcentaje equitativo para cada uno (20% por tratarse de 5 procesos). Con estos pesos, se aplicó la siguiente fórmula para determinar el factor de relevancia del proceso: 𝑃𝑒𝑠𝑜𝑃𝑟𝑜𝑐𝑒𝑠𝑜 ∗ (∑𝑃𝑒𝑠𝑜𝑃𝑟𝑜𝑏𝑙𝑒𝑚𝑎𝑁𝑒𝑔𝑜𝑐𝑖𝑜 ∗ 𝐶𝑎𝑙𝑖𝑓𝑖𝑐𝑎𝑐𝑖ó𝑛𝐴𝑠𝑖𝑔𝑛𝑎𝑑𝑎) La Tabla 4.5 muestra los resultados obtenidos de la aplicación de la fórmula anterior y ayuda a determinar el orden en el cual la mejora debe ser aplicada en los procesos de la organización. Objetivo Peso % 1. Actualización de la oferta de soluciones y desarrollo de nuevas aplicaciones. 9 25.71% 2. Posicionar la marca XXXXX como estrategia de llegada a los mercados externos. 8 22.86% 3. Mejorar la atención post venta al cliente. 7 20.00% 4. Implementar la Norma ISO/IEC 29110 para desarrollo de software. 6 17.14% 5. Explorar mercados externos a través de la alianza con distribuidores en países como: Panamá, México, Chile, Colombia. 5 14.29% Problema Peso % 1. No hacen uso de ningún tipo de indicador para medir el éxito de los proyectos completados. 8 17.78% 2. Incumplimiento de plazos fijados con el cliente. 9 20.00% 3. La calidad de sus productos no es siempre la mejor. 10 22.22% 4. No hay documentación de los procesos que realizan. 6 13.33% 5. El mantenimiento del software que ofrecen no es el más adecuado. 5 11.11% 6. No hay planeamiento estratégico 7 15.56% 57 Según la Tabla 4.5, se puede apreciar que en primer lugar se debería comenzar por el proceso de Gestión del Portafolio de Proyectos; en segundo lugar, se debería ejecutar la mejora sobre el proceso de Implementación de Software; en tercer lugar, se debería dar importancia al proceso de Gestión de Proyecto; en cuarto lugar, se debería considerar el proceso de Gestión de Recurso; y, finalmente, el proceso de Gestión de Procesos. Tabla 4.4 Objetivos de negocio vs Problemas de negocio ¿Cuál es el impacto que tiene el Problema con respecto del Objetivo de negocio? Puede ser Alto, Medio o Bajo Prob01 Prob02 Prob03 Prob04 Prob05 Prob06 No hacen uso de ningún tipo de indicador para medir el éxito de los proyectos completados . Incumplimien to de plazos f ijados con el cliente. La calidad de sus producto s no es siempre la mejor. No hay documentac ión de los procesos que realizan. El mantenimien to del software que ofrecen no es el más adecuado. No hay planeamie nto estratégico 0.17 0.20 0.22 0.13 0.11 0.15 Obj1 1. Actualización de la of erta de soluciones y desarrollo de nuev as aplicaciones. 0.27 Media Baja Baja Baja Alta Media Obj2 2. Posicionar la marca XXXX como estrategia de llegada a los mercados externos. 0.22 Alta Alta Alta Baja Media Baja Obj3 3. Mejorar la atención post v enta al cliente. 0.20 Baja Alta Media Media Alta Baja Obj4 4. Implementar la Norma ISO 29110 para desarrollo de sof tware. 0.17 Media Media Alta Media Media Baja Obj5 5. Explorar mercados externos a trav és de la alianza con distribuidores en países como: Panamá, México, Chile, Colombia. 0.14 Baja Baja Baja Baja Baja Media Factor de relevancia del problema 0.38 0.49 0.53 0.18 0.31 0.22 58 Tabla 4.5 Problemas de negocio vs. Procesos 4.3.2 Propuesta del Plan de Mejora En base a los resultados obtenidos de la priorización de procesos y con las entrevistas mantenidas con el jefe de Proyectos se pudo determinar el orden de los procesos a mejorar. A partir de esta selección, el tesista planteó las mejoras que consideró fundamentales para que el flujo de cada proceso sea más eficiente y sobre todo para que los problemas de negocio se atenúen. Esta propuesta de mejora incluye cambios en el flujo de los procesos, adición de formatos e inclusión de nuevas herramientas para automatizar las actividades. 4.3.2.1 Diseño de procesos del Plan de Mejora Tras una reunión con el jefe de Proyectos y bajo la aprobación de la Gerencia se determinó el siguiente orden para aplicar el ciclo de mejora. En primer lugar, se otorgó a la Gestión del Portafolio de Proyectos toda la atención; puesto que, la Gerencia consideró que si no gestionaba adecuadamente todos sus proyectos en cursos entonces sus aspiraciones y objetivos no se verían realizados. En segundo lugar, el jefe de Proyectos identificó que el proceso de Implementación de Software necesitaba un rediseño para mejorar la calidad de los productos de software finales. Es por ello que, este proceso fue ¿Cómo contribuye la implementación del Proceso en la resolución del Problema? Puede ser Alto, Medio o Bajo SI PM PSM RM PPM Implementación de Sof tware Gestión de Proy ecto Gestión de Procesos Gestión de Recursos Gestión de Portaf olio de Proy ectos 20.00% 20.00% 20.00% 20.00% 20.00% Prob01 1. No hacen uso de ningún tipo de indicador para medir el éxito de los proy ectos completados. 0.37 Baja Alta Baja Baja Alta Prob02 2. Incumplimiento de plazos f ijados con el cliente. 0.49 Alta Media Baja Media Media Prob03 3. La calidad de sus productos no es siempre la mejor. 0.53 Media Media Media Alta Media Prob04 4. No hay documentación de los procesos que realizan. 0.18 Baja Baja Alta Baja Baja Prob05 5. El mantenimiento del sof tware que of recen no es el más adecuado. 0.30 Media Baja Media Baja Baja Prob06 6.No hay planeamiento estratégico 0.21 Baja Baja Baja Baja Alta Factor de relevancia del proceso 0.88 0.85 0.70 0.84 0.98 59 el segundo sobre el cual se trabajaron las mejoras. Finalmente, por cuestiones de tiempo, se dejó en tercer lugar a la Gestión de Proyecto. La gerencia consideró que si se mejoraba primero el Portafolio de Proyectos entonces la Gestión de Proyectos indudablemente también mejoraría. Esto último fue verdad ya que cuando se plantearon las mejoras para este tercer proceso, muchas de ellas ya habían sido consideradas dentro del portafolio. 4.3.2.2 Situación Inicial En la empresa se venía afrontando problemas relacionados al factor tiempo (incumplimiento de plazos fijados), al planeamiento estratégico y a la medición del éxito cuando culminaban sus proyectos. En base al análisis desarrollado, se pudo detectar que tales agentes impactaban negativamente en el posicionamiento de la marca XXXXXX en los mercados externos. Así mismo, la actualización de la oferta de soluciones y el desarrollo de nuevas aplicaciones se veían afectados críticamente por estos inconvenientes. Cabe añadir que, la empresa tenía inconvenientes con la calidad de los productos que ofrece. Aunque el porcentaje de baja calidad no era alto, la mejora del servicio post venta, la implantación de la norma ISO 29110 y el desarrollo de nuevas aplicaciones estaban siendo impactados negativamente de acuerdo al levantamiento de información realizado. Por último, otro objetivo del negocio que estaba comprometido directamente era la exploración de nuevos mercados en el extranjero. A. Gestión del Portafolio de Proyectos Esta situación presentada era consecuencia del diseño anterior de sus procesos. A continuación se mostrará el flujo inicial del primer proceso sobre el cual se aplicó el ciclo de mejora en la Figura 4.8. Este proceso presentaba los siguientes objetivos: 1. Mantener diariamente actualizado el Cuadro de Control para el seguimiento de Proyectos vigentes y programados. 2. Informar semanalmente a la Gerencia General sobre el Cuadro de Control para el seguimiento de los Proyectos. 3. Incorporar los nuevos Proyectos al Cuadro de Control para el seguimiento de Proyectos sin que estos afecten el normal proceso de los Proyectos vigentes, considerando los recursos que intervienen. 4. Registrar los motivos de retraso de algún proyecto y las acciones correctivas tomadas. 60 Sin embargo, la forma adoptada para cumplir con estos objetivos no era la más adecuada. En primer lugar, no hacían uso de ningún tipo de indicador para medir el éxito de los proyectos completados. Además de esto, no evaluaban o comparaban, al finalizar cada proyecto, si lo que se había estimado era realmente lo que se había solicitado en el proyecto. De esto se puede comentar que solo se enfocaban en que el proyecto se haya completado de cualquier forma (pero sin usar más recursos) para seguir realizando más proyectos. . En ciertas ocasiones, los proyectos se retrasaban por la demanda de atender nuevos proyectos y descuidaban los que ya se habían iniciado. El equipo actuaba de manera reactiva frente a lo que podía suceder debido a que no había un adecuado planeamiento. Finalmente, el monitoreo y seguimiento no era completo porque el Jefe de proyectos no podía abastecerse ya que en ocasiones tenía que encargarse de la fase de análisis de los proyectos. Figura 4.8 Mapa de Procesos Inicial del Portafolio de Proyectos B. Implementación de Software El segundo proceso sobre el cual se aplicó el ciclo de mejora fue sobre la Implementación de software. El flujo inicial de este proceso puede apreciarse en la figura 4.9. Este proceso presentaba los siguientes objetivos: 1. Implementar un control para las inducciones realizadas por el Analista hacia el Desarrollador, al iniciar la etapa de Desarrollo. 2. Documentar todas las pruebas unitarias que realiza el desarrollador, indicado los casos de prueba realizados. 3. Implementar un control en el pase del Desarrollo hacia el área de calidad para las pruebas de sistemas. El cumplimiento de estos objetivos no se estaba realizando íntegramente. El segundo objetivo, por ejemplo, nunca se realizaba; puesto que, los desarrolladores no documentaban prácticamente nada. En primer lugar, el testeo de los productos no se realizaba completamente, el equipo otorgaba muy pocos días para realizar los casos de prueba (por lo general 3 días antes de que se terminara el desarrollo).En consecuencia, no se realizaban todos los tipos de pruebas aplicables porque la fecha de entrega estaba próxima (entre ellas las pruebas de estrés). Cabe mencionar que el analista de pruebas era quien realizaba los casos de prueba pero éste no participaba desde la elaboración del catálogo de requisitos (Ojo: No documentado formalmente sino detallado en la propuesta técnica- económica) por lo que no conocía con exactitud cuáles debían ser las salidas de cada requisito. Esto podría también llevarle más tiempo en determinar que pruebas eran aplicables. En segundo lugar, muchas veces la funcionalidad del software no era la esperada por el cliente. Esto es posible porque no había un contacto directo con el usuario final del software para detallar más los requerimientos ya que es éste quién finalmente usaba el software. El cliente muchas veces no permitía que el usuario final sea entrevistado porque éste estaba realizando otras labores en su empresa. En tercer lugar, el equipo de desarrollo estimaba de manera inadecuada el tiempo que les demandaría investigar las nuevas tecnologías (equipos de hardware) que aparecen en el mercado; en este caso, intentaban compensar la demora agilizando las demás actividades. En cuarto lugar, se fiaban en la experiencia propia del negocio debido a que por lo general el cliente solicitaba la instalación o entrega del producto en un par de días después de la fecha compromiso porque no disponía de tiempo en el momento. 63 Finalmente, gracias a un focus group que realizó el departamento de Marketing, se pudo obtener cierta información acerca del mantenimiento de software que la empresa brindaba. De este documento se concluye que, en ciertos casos (20% de las actualizaciones), el cliente espera que se le pueda dar un servicio de actualización ya que realizan una inversión en un producto y muchas veces este producto no abarca todas sus expectativas (agregar dos campos más, aumento del tamaño del campo, etc.). Se ha añadido el proceso de mantenimiento en esta sección porque la norma ISO/IEC 29110 no tiene un proceso de mantenimiento separado. C. Gestión de Proyecto El tercer proceso sobre el cual se aplicó el ciclo de mejora fue sobre la Gestión de Proyecto. El flujo inicial de este proceso puede apreciarse en la Figura 4.10 y su parte complementaria en la Figura 4.11. Este proceso presentaba los siguientes objetivos: 1. Recibir la conformidad del cliente, según los tiempos establecidos en el cronograma del proyecto. 2. Completar el 100% del alcance del Proyecto con los tiempos y recursos estimados en el cronograma del proyecto, sino se tuviera incidencias por el lado del cliente. 3. Identificar de manera temprana alguna afectación que no permita el cumplimiento del Proyecto, en cantidad, tiempo y costo. El cumplimiento de estos objetivos tampoco se realizaba en un inicio. Por ejemplo, el tercer objetivo no se estuvo cumpliendo de manera eficiente. Esto debido a que LIM.DELTA no elaboraba una gestión de riesgos y, por ende, no había una forma de como prever los riesgos potenciales de cada proyecto. Así mismo, no había estrategias de copias de seguridad ni de versiones. Figura 4.9 Mapa de Procesos Inicial de la Implementación de Software Figura 4.10 Mapa de Proceso Inicial de la Gestión de Proyecto Figura 4.11 Mapa de Procesos de la Preventa 4.3.2.3 Situación de mejora A continuación se detallará la situación de mejora a la que se deseaba alcanzar a través de la propuesta de mejora que se ofreció por cada proceso a mejorar. Para cada proceso se propuso un objetivo de mejora mapeado con los objetivos de negocio que encerraba, se rediseñó el flujo de las actividades y se designó el uso de herramientas para automatizar muchas actividades. A. Gestión del Portafolio de Proyectos En la Tabla 4.6 se muestra el mapeo entre el objetivo de mejora del portafolio con los objetivos del negocio que se encuentran involucrados así como los problemas que se estarían resolviendo con la propuesta que se planteó. Para la Gestión del Portafolio de Proyectos y de acuerdo a la problemática presentada anteriormente, se recomendó realizar, en primera instancia, la documentación de las políticas del portafolio de proyectos ya que estas sirven para guiar las actividades. Asimismo, para tener un mejor control de todos los proyectos se sugirió utilizar una herramienta de licencia abierta llamada PPM Talaia. Esta herramienta hará uso de indicadores de gestión los cuales permitirán controlar el desempeño del proceso y generar reportes útiles para los interesados. Se sugirió también, durante las visitas con el cliente o de manera virtual, completar un formato de reclamos/quejas así como un registro de las medidas correctivas que se emplearon para tenerlos en consideración al finaliza el flujo, esto debido a que también se propuso elaborar sugerencias de mejora con todo el equipo. Por otro lado, es imprescindible que todo tipo de documento que se elabore sea revisado por un segundo. En este caso, se sugirió que el gerente sea quien revise los documentos que realiza el jefe de proyectos y dé sus anotaciones. Finalmente, la organización debe realizar el planeamiento estratégico para qué nutra a este proceso con los objetivos de negocio para ello se proporcionó un formato sencillo que sintetice el planeamiento. El nuevo flujo del Portafolio de Proyectos se muestra en la Figura 4.12. 68 Tabla 4.6 Objetivo de Mejora/Objetivos de Negocio/Problemas del Portafolio de Proyectos Objetivo de Mejora: Lograr una adhesión al proceso de al menos 85% de las prácticas del proceso, siendo el esperado de 95%. Objetivos de negocio afectados: 1. Posicionamiento de la marca XXXXX en los mercados externos. 2. Actualización de la oferta de soluciones y el desarrollo de nuevas aplicaciones. 3. Exploración de nuevos mercados en el extranjero. 4. Mejorar el servicio post venta. Problemas que contribuye a resolver: 1. No hacen uso de ningún tipo de indicador para medir el éxito de los proyectos completados. 2. Incumplimiento de plazos fijados con el cliente. 3. No hay planeamiento estratégico. B. Implementación de Software En la Tabla 4.7 se muestra el mapeo entre el objetivo de mejora del portafolio con los objetivos del negocio que se encuentran involucrados así como los problemas que se estarían resolviendo con la propuesta que se planteó. En base a los problemas detectados, se propuso, en primer lugar, especificar de manera más detallada los requerimientos dentro de la propuesta técnica para asegurar que el cliente tiene conocimiento de lo que se acordó inicialmente. En la 69 propuesta técnica solo iría una descripción a alto nivel del producto en sí. Así mismo, para obtener seguridad en la validación de requerimientos, se propuso que el analista realice una visita al cliente (presencial o virtual) con el catálogo de requerimientos y este le explique cada requerimiento. De igual modo, se recomienda que el analista realice la verificación de los requisitos con el jefe de calidad y se complete un formato que acredite dicha actividad. Esto ayudará a que el jefe de calidad se nutra desde el inicio con el detalle de los requisitos y pueda elaborar mejor el plan de pruebas. Otro aspecto que se está considerando como parte de la mejora del proceso, es integrar una hoja de cálculo para llevar la trazabilidad del software y utilizar una herramienta para automatizar scripts de prueba (JMeter). Tabla 4.7 Objetivo de Mejora/Objetivos de Negocio/ Problemas de la Implementación de Software Objetivo de Mejora: Lograr una adhesión al proceso de al menos 85% de las prácticas del proceso, siendo el esperado de 95%. Objetivos de negocio afectados: 1. Actualización de la oferta de soluciones y desarrollo de nuevas aplicaciones. 2. Mejorar la atención post venta al cliente. 3. Implementar la Norma ISO 29110 para desarrollo de software Problemas que contribuye a resolver: 1. La calidad de sus productos no es siempre la mejor. Además, es importante que cada documento que se realice sea verificado por un segundo para asegurar la consistencia de este y que posteriormente se integre con el resto de los documentos. Por otro lado, se propuso un formato en donde los desarrolladores puedan registrar las pruebas unitarias que ejecutan de tal manera que éste sirva como base para los testers (evitar doble trabajo). 70 Así mismo, se sugirió que el equipo de calidad elabore también un manual de instalación y que estos proporcionen información a los clientes sobre enlaces que contengan información referente al hardware que venden con el software. Finalmente, se aconsejó que la documentación de los proyectos que pertenecen a mantenimiento de software se relacione en una hoja de Excel con el proyecto original o con los proyectos previos con el fin de acceder rápidamente a la información y no desperdiciar tiempo realizando actividades o documentos ya elaborados. El nuevo flujo del proceso de Implementación se muestra en la Figura 4.13. Cabe resaltar que, este flujo fue propuesto para usarse cuando se tengan nuevos proyectos por realizar (desde cero). Es por ello que, en la Figura 4.14 se muestra el flujo de Mantenimiento de Software propuesto para proyectos en donde el cliente exige una actualización o adición de nuevas funcionalidad a un proyecto ya trabajado. Este flujo ha sido adaptado del modelo Competisoft. No se contemplan todas las actividades porque para el caso de LIM.DELTA fue suficiente integrar solo ciertas actividades. C. Gestión de Proyecto En la Tabla 4.8 se muestra el mapeo entre el objetivo de mejora de la Gestión de Proyecto con los objetivos del negocio que se encuentran involucrados así como los problemas que se estarían resolviendo con la propuesta que se planteó. Debido a la problemática que presentaba LIM.DELTA, se ofreció un formato sencillo de gestión de riesgos, el cual contemplaría solo los principales riesgos (por lo general para los proyectos pequeños) a fin de no abrumar a la organización con mucha documentación. Así mismo, se sugirió una estrategia de copias de seguridad del tipo diferencial a mitad del proyecto (proyectos de 1 a 2 semanas) y la misma estrategia diferencial pero de manera semanal para proyectos medianos y grandes (1 mes a más). Por otro lado, se recomendó usar un control de versiones con la herramienta libre SVN (integrado con tortoise). Esto con la finalidad de tener copias de sus proyectos disponibles y funcionando. Así mismo, este último es parte de la gestión de riesgos. Además de esto, como se mencionó anteriormente en la Gestión del Portafolio, la herramienta Talaia Open ayudó a la Gestión de Proyecto con el cronograma y la integración de los diferentes elementos que lo componen (costos, esfuerzo, riesgos, 71 versiones, objetivos, etc.). En la Figura 4.15 se muestra el nuevo flujo que se propuso para la Gestión de Proyecto. Tabla 4.8 Objetivo de Mejora/Objetivos de Negocio/ Problemas de la Gestión de Proyecto Objetivo de Mejora: Lograr una adhesión al proceso de al menos 85% de las prácticas del proceso, siendo el esperado de 95%. Objetivos de negocio afectados: 1. Actualización de la oferta de soluciones y desarrollo de nuevas aplicaciones. 2. Posicionar la marca XXXXX como estrategia de llegada a los mercados externos. 3. Mejorar la atención post venta al cliente. 4. Implementar la Norma ISO 29110 para desarrollo de software. 5. Explorar mercados externos a través de la alianza con distribuidores en países como: Panamá, México, Chile, Colombia. Problemas que contribuye a resolver: 1. No hacen uso de ningún tipo de indicador para medir el éxito de los proyectos completados. 2. Incumplimiento de plazos fijados con el cliente. 3. La calidad de sus productos no es siempre la mejor. 4. No hay planeamiento estratégico. Figura 4.12 Mapa de Procesos Final de Portafolio de Proyectos Figura 4.13 Mapa de Proceso Final de la Implementación de Software (Proyectos Nuevos) Figura 4.14 Mapa de Procesos del Mantenimiento de Software (Proyectos de Actualización) 75 Figura 4.15 Mapa de Procesos Final de la Gestión de Proyecto 4.4 Ejecución de las mejoras La ejecución de las mejoras en LIM.DELTA fue dirigida, en cierta manera, de acuerdo a la priorización de procesos. Esto debido a que, según el orden para llevar a cabo un proyecto, primero se gestiona el portafolio de proyectos, luego se gestiona un proyecto y finalmente se implementa el software del proyecto (en la priorización se obtuvo este orden: Gestión del portafolio de proyectos, implementación de software y gestión de proyecto). Para la ejecución de las mejoras se tomaron dos proyectos de LIM.DELTA para evaluar la efectividad de las propuestas brindadas. Cabe mencionar que esta selección de proyectos fue tomada en base a una clasificación de proyectos que se realizó a partir del levantamiento de información efectuada en la etapa de inducción. Esta clasificación considera como proyectos pequeños, aquellos cuya duración está entre una semana y tres; como medianos, aquellos entre cuatro y doce semanas; y grandes, aquellos mayores a doce semanas. Para la experiencia de mejora se tomó un proyecto pequeño y uno mediano para obtener resultados más precisos sobre los formatos y herramientas propuestas. A. Gestión del Portafolio de Proyectos La principal mejora que se sugirió implementar en este proceso fue la incorporación de una nueva herramienta que permitiera gestionar todos los proyectos que la organización apertura. Esta recomendación partió de las reuniones que se tuvieron con el jefe de proyectos durante la etapa de inducción. Se trató de ubicar una herramienta que ayude a la organización a integrar la documentación, que maneje buenas prácticas y sobre todo que no le genere un impacto considerable sobre sus finanzas Al inicio, el tesista tuvo que lidiar con algunas consideraciones técnicas para poder tener la herramienta operativa, pero finalmente pudo dejar la herramienta en producción. Así mismo, el tesista tuvo inconvenientes con el funcionamiento de esta herramienta, ya que no existía un manual o guía de usuario. Además de esto, hubo ciertos retrasos con el jefe de proyectos para llevar a cabo las capacitaciones correspondientes. 77 Pese a estos contratiempos y dificultades, se pudo aprovechar el potencial de la herramienta como se esperaba. El jefe de proyectos estuvo satisfecho con los beneficios que ésta otorgó al proceso. La herramienta permitió seguir en un 90% las actividades que la norma contempla bajo la integración de los documentos, la gestión de riesgos y el monitoreo continuo. Dado que la herramienta para gestionar los proyectos carecía de manuales, el tesista documentó uno con las funcionalidades principales que la empresa realmente utilizaba. Cabe resaltar que, esta herramienta tenía muchas funcionalidades porque se basaba en estándares PMI e ISO; sin embargo, debido a la dimensión de la organización, solo se adecuó aquellas que LIM.DELTA podía administrar, ya que se buscaba generar una mejora en sus procesos y no imponer herramientas o documentación que no genere provecho. Por otro lado, se colocó en producción el uso de un formato de RECLAMOS/QUEJAS/CONTRATIEMPOS que ayudará a la mejora continua de este proceso. La norma exige la presencia de actividades de mejora y, es por ello que, este formato se decidió incorporar en LIM.DELTA. Esta plantilla es muy sencilla, pues tiene tres secciones principales. Una que contiene el nombre del proyecto, otra donde se detalla el problema y otra donde se especifica las acciones correctivas. El llenado de este formato le permitió al jefe de proyectos darse cuenta que las políticas del portafolio necesitaban un reajuste a fin de evitar inconvenientes similares en el futuro. Otro formato que se incluyó en la propuesta de mejora y que se puso en producción es el formato de planeamiento estratégico. Como se mencionó en el capítulo anterior, la organización no tenía definido los objetivos de negocio desde que el tesista pisó la empresa. Esta plantilla le ayudó a LIM.DELTA a plasmar sus objetivos y a trazar una estrategia en base a los proyectos que desarrollaba (internos) y a los proyectos a medida (externos) con el fin de que estos objetivos sean alcanzados en el corto mediano y largo plazo. El gerente comprendió la importancia de contar con un planeamiento estratégico en la organización y justificó la importancia de completarlo de ahora en adelante. Es importante destacar que, debido a la dimensión de la organización, el jefe de proyectos era quien estaba a cargo de realizar todo este proceso y el gerente, de hacer ciertas revisiones. 78 B. Gestión de Proyecto La ventaja que se obtuvo de haber priorizado la gestión del portafolio de proyectos fue que muchas de las actividades que la norma exige fueron contempladas dentro de la gestión del portafolio de proyectos a través de la herramienta propuesta para este proceso. De acuerdo a lo mencionado anteriormente, solo se propuso un formato llamado MATRIZ DE RIESGOS. Esta plantilla fue sugerida; puesto que, la organización no gestionaba ningún tipo de riesgos en el proyecto y esta ayudó al jefe de proyectos a tener conciencia de la importancia que es mapear y monitorear los riesgos para evitar contratiempos. El formato propuesto tiene las siguientes secciones: Identificador: En esta sección se debe colocar un valor referencial que identifique a un determinado riesgo. Descripción: Aquí se detalla o describe el riesgo en concreto del que se habla. Tipo: La tipología que se ha usado clasifica a los riegos en: Riesgos del proyecto, de producto y proyecto/producto. Probabilidad de ocurrencia: Esta parte se completa con un porcentaje basado en la experiencia y otros factores del propio proyecto. Impacto: En esta sección se califica la importancia del riesgo para el proyecto (1 al 10). Severidad: Aquí se especifica la criticidad del riesgo (alto, medio o bajo). Disparador: Se debe colocar algún síntoma o señal que indique cuando el riesgo está por materializarse. Acciones de mitigación: Se colocan acciones para evitar que el riesgo se materialice. Acciones de corrección: Se colocan las acciones a tomar cuando el riesgo ya se materializó. Responsable: Se completa con el nombre de la persona que estará monitoreando el riesgo. Este formato no es complicado de llenar pero se observó que en proyectos pequeños no era muy recomendable usarse y que bastaba usar la sección de gestión de riesgos de la herramienta implantada en el portafolio de proyectos. 79 Por otro lado, según la evaluación diagnóstica, LIM.DELTA no manejaba la gestión de versiones de manera adecuada en sus proyectos. En ese sentido se propuso el uso de dos herramientas de código abierto. En un principio el jefe de proyectos no estaba muy entusiasmado con la idea; puesto que, en años anteriores habían tenido problemas con herramientas similares para este tipo de tareas. Sin embargo, durante la puesta en marcha, el equipo de desarrollo como el jefe de proyectos consideró el aporte que estas herramientas brindaban a sus proyectos. Estas herramientas eran muy flexibles pues no solo permitía gestionar versiones de archivos sino también el código de los desarrolladores en cualquier lenguaje de programación. Finalmente, se valoró la importancia de contar con la estrategia de copias de seguridad de manera diferencial. Esta estrategia se terminó de definir dentro del piloto desarrollado y en base a éste se determinó que para proyectos pequeños se harían copias semanales y para proyectos medianos y grandes se realizarían copias quincenales. C. Implementación del Software Uno de las mejoras que les costó más trabajo implementar a la organización en este proceso fue la elaboración del catálogo de requisitos de manera coherente. LIM.DELTA no tenía la costumbre de definir sus requerimientos más que a alto nivel y sin una verificación y validación formal. Para seguir las actividades que la norma establece, la empresa ahora adjunta el catálogo de requerimientos a la propuesta técnica y estos requerimientos son verificados con el formato VERIFICACION DE REQUISITOS propuesto y validados con el cliente en una reunión virtual o presencial según las condiciones del caso. El analista como el jefe de proyectos comprendió la importancia que tiene un catálogo de requisitos y es por ello, que este se elabora para todo tipo de proyectos (pequeños, medianos y grandes). Está claro que el tamaño de éste varía de acuerdo al tipo de proyecto y por lo tanto no ocasiona ningún retraso en la ejecución de los proyectos. Durante el piloto también se puso en cuestión el formato MATRIZ DE TRAZABILIDAD, el equipo de desarrollo no tenía mucha confianza en usar ese formato porque lo veía como un desperdicio de tiempo. Sin embargo, durante el proyecto piloto el uso de la matriz permitió al equipo ahorrar tiempo en muchas 80 actividades que realizaban sistemáticamente. Así mismo, les ayudó a ordenar su forma de trabajo al mapear requerimientos con casos de uso, casos de prueba y otros artefactos de diseño. La responsabilidad de elaborar la matriz de trazabilidad fue asignada al analista funcional; sin embargo, el llenado de ésta era realizado por los diferentes miembros del área de sistemas. Para esto, éste archivo fue colocado en la nube a fin de que todos pudieran hacer las modificaciones correspondientes y el analista era quien se encargaba de supervisar el estado del documento. Otro formato que resultó de gran utilidad durante la ejecución del piloto fue la plantilla de PRUEBAS UNITARIAS. Esta plantilla fue elaborada; puesto que, el jefe de proyectos en una de las reuniones comentó que durante la ejecución del plan de pruebas se levantaban observaciones de criticidad cuatro (la más alta en el rango establecido por LIM.DELTA). Los desarrolladores estuvieron de acuerdo con el llenado de dicho formato porque de esa manera podían reducir la cantidad de errores en el software y LIM.DELTA también lograría mejorar la calidad de sus productos. Este documento ayudó al área de calidad en la ejecución de los casos de prueba debido a que ellos revalidaban las pruebas que los desarrolladores habían ejecutado (volvían a ejecutar los mismos casos de prueba de los desarrolladores). De esa manera, la ejecución de las pruebas tuvo un papel más riguroso del que solía desempeñar. El jefe de proyectos también destacó en una las reuniones iniciales que muchos de los problemas que tenían con sus clientes eran debido a que el equipo de pruebas no realizaba tests de estrés y/o rendimiento. Es decir, cuando el desarrollador y los testers probaban el software solo lo hacían con una máquina o a lo mucho dos en paralelo. El tesista nuevamente consideró los costos que podría originar la incorporación de una nueva herramienta de pruebas así como el tiempo que tomaría familiarizarse con ésta. Luego de una investigación constante, el tesista se capacitó y enseñó al equipo de pruebas como usar una herramienta libre que soportaba lo que LIM.DELTA necesitaba. El equipo de pruebas estuvo muy satisfecho con las funcionalidades que la herramienta les ofreció y por su parte también comenzó a ordenar la documentación de las pruebas e indagar como automatizar pruebas funcionales que eran repetitivas del día a día. El tesista les orientó con algunas 81 de estas herramientas de uso libre; sin embargo, también les sugirió el uso de paquetes más completos que ya requerían el pago de una licencia. 4.5 Evaluación de las mejoras En la etapa inicial del proyecto, se realizó una evaluación diagnóstica para medir el grado de adhesión de los procesos existentes de LIM.DELTA con los procesos de la norma ISO 29110. Después de que se ejecutaron las mejoras sobre los proyectos piloto, el tesista también realizó este proceso de evaluación con la finalidad de obtener resultados tangibles sobre cómo éstas propuestas de mejora habían afectado a los procesos del área de sistemas. Cabe resaltar que se realizaron dos evaluaciones, una realizada por el tesista (evaluación teórica) y otra por el evaluador (en este caso a cargo del investigador principal).El reporte técnico con los resultados obtenidos de la evaluación final se presentan en el ANEXO 6. A continuación se muestran los resultados obtenidos por el evaluador en la Tabla 4.9. Tabla 4.9 Nivel de cumplimiento de procesos al final del ciclo de mejora P R O C E S O S PM SI RM PSM PPM % cumplimiento 90.3 89.4 40.7 15.5 90.0 Grado de cumplimiento F F P P F Nivel 1 1 0 0 1 En la Figura 4.16 se muestra el perfil de capacidades de procesos a final del primer ciclo de mejora elaborado por el tesista. Figura 4.16 Perfil de capacidades 100.0% 93.3% 91.5% 40.8% 20.7% 90.0% 0.00% 50.00% 100.00% 150.00% Referencia PM SI RM PSM PPM 82 Esta evaluación teórica (no aplicada aún sobre los pilotos) realizada durante este primer ciclo de mejora obtiene los siguientes resultados:  El objetivo de mejora trazado para el proceso de Gestión del Portafolio de Proyectos era del 85%. Sin embargo, gracias a las mejoras añadidas al proceso se espera que este proceso alcance el 90.3% de cumplimiento con la cual se lograría alcanzar el primer nivel.  En el caso del proceso de Implementación del software se logró obtener el 89.4% de cumplimiento con lo cual se superaría el objetivo trazado inicial de 85% y se estaría también alcanzando el nivel uno en este primer ciclo de mejora  Para el tercer proceso priorizado también se fijó como objetivo alcanzar al menos el 85%. Nuevamente, este valor fue superado, según la evaluación realizada, y el proceso alcanzó el 90.0% de cumplimiento y lograría obtener el primer nivel dentro de este primer ciclo de mejora. De acuerdo a estos resultados, si se compara el nivel de cumplimiento de cada proceso al inicio y al final del ciclo de mejora se tendría lo siguiente: Tabla 4.10 Comparativo Inicial vs. Final del nivel de cumplimiento de cada proceso P R O C E S O S PM SI RM PSM PPM %cumplimiento a Inicio 47.1 57.5 44.7 0.0 28.3 %cumplimiento al final 90.3 89.4 44.7 15.5 90.0 Variación % respecto al inicio 91.7 55.4 0.0 15.5 218.0 De estos resultados, se puede comentar que la Gestión de proyecto mejoró su nivel de cumplimiento sobre los procesos de la norma en más del 90% respecto al cumplimiento o forma de trabajo inicial. Así mismo, el proceso de implementación de software incrementó en más del 55% su grado de cumplimiento respecto a la ejecución de las actividades en 83 un inicio. No hubo variación alguna sobre la Gestión de Recursos pero sí sobre la Gestión de procesos. Este incremento es atribuible a la elaboración y ordenamiento de la documentación que no existía en la etapa inicial del proyecto. Finalmente, la Gestión del Portafolio de Proyectos sería el proceso que recibiría mayor beneficio; puesto que, su nivel de cumplimiento respecto al inicial aumentaría a más del doble. Así mismo, como parte de las mediciones finales realizadas, se evaluó el esfuerzo desplegado durante todo el proyecto. Este esfuerzo considera la participación del equipo de trabajo de la empresa LIM.DELTA, las visitas realizadas por el investigador local, las reuniones con el ingeniero Abraham Dávila y el tiempo que el tesista dedicó como facilitador en la organización. El resumen de esta valoración se puede apreciar en la Tabla 4.5; sin embargo, el detalle se encuentra en un repositorio del proyecto. Tabla 4.11 Esfuerzo del proyecto (en horas) 4.6 Problemas identificados y acciones tomadas Durante la primera etapa del proyecto, surgió un retraso que no permitió continuar a los tesistas con las demás fases del ciclo de mejora. Sin embargo, tales riesgos estaban ya mapeados en la matriz de riesgos del proyecto y las acciones correctivas fueron puestas en práctica. Esto permitió que los tesistas puedan continuar con el desarrollo del proyecto y entregar sus resultados en las fechas solicitadas. En varias fases del proyecto, se ha percibido retrasos por parte del jefe de proyectos. Debido a que este no le dio la importancia suficiente al proyecto de mejora. Gracias a las visitas locales fue que se pudo redistribuir compromisos y reasignar actividades pendientes. Participante Nro. Horas Empresa LIM.DELTA -Coordinaciones 65hrs. Empresa LIM.DELTA- Implantación de procesos 89hrs. Andrés Suarez (tesista) 377hrs. Luis Flores (investigador local) 20hrs. Abraham Dávila 30hrs. TOTAL 581hrs. 84 Durante la etapa de ejecución de las mejoras, no se tenía un proyecto piloto qué aprovechar; puesto que, la etapa de fiestas navideñas estaba comenzando. El jefe de proyectos reprogramó la ejecución de los pilotos para después de estas fechas pero tomó ventaja de este tiempo para relacionarse con las herramientas y formatos propuestos. Así mismo, se aclararon dudas de la capacitación realizada. 85 5 Observaciones, conclusiones y mejora En esta sección se recogen todas las observaciones interesantes del proyecto; conclusiones finales sobre la ejecución del ciclo de mejora; y recomendaciones de ayuda para un siguiente ciclo de mejora y para la organización. 5.1 Observaciones La empresa no contaba con herramientas de automatización de ningún tipo. Se basaban en Office para realizar casi todas sus actividades a parte de aquellas que eran netamente para la programación. Es por ello que en la propuesta se sugirieron el uso de herramientas que complementen sus actividades cotidianas. Por otro lado, se tuvo que complementar el ciclo de mejora con el modelo COMPETISOFT ya que la norma no contempla el proceso de MANTENIMIENTO de software. El seguimiento de este proceso es típico de proyectos pequeños (1-3 semanas). La gerencia no estaba comprometida como debería ser. Esto puede ser porque esta laboraba desde Miami y venía a Lima cada tres meses para supervisar el avance de los distintos proyectos de sus clientes. Todas las decisiones se las dejaban a criterio de los empleados y solo se restringía a exigir resultados. Pese a esta desventaja de dirección, el equipo de desarrollo y pruebas siempre estuvo dispuesto a colaborar con el proceso de mejora. En todo momento, vertían sus opiniones y consejos. Así mismo, realizaban preguntas con el fin de aprender e involucrarse mucho mejor con los flujos procedurales propuestos. Es importante destacar que debido a la dimensión de la empresa (pequeña), la existencia de múltiples roles fue inevitable. La peor parte la llevo el jefe de proyectos ya que este tenía alrededor de cuatro roles a cargo. La empresa LIM.DELTA carecía de tesistas en sus instalaciones. En ese sentido, el personal con el que laboraba se le podía considerar como apto e instruido para desempeñar las diferentes funciones a los que estaban asignados. Sin embargo, existían temas en los que necesitaban ser capacitados. Según el levantamiento de información que se obtuvo en un inicio, el personal del área de desarrollo no registraba antecedentes de capacitaciones en los dos últimos años. 86 Se observó cierto grado de satisfacción con las propuestas de mejora sugeridas en los diferentes procesos trabajados. El jefe de proyectos y la gerencia estuvieron dispuestos a participar de un segundo ciclo de mejora para levantar todos los pendientes y ejecutar el ciclo de mejora en aquellos procesos que no fueron priorizados. 5.2 Conclusiones Se logró ejecutar eficazmente un primer ciclo de mejora sobre una pequeña organización desarrolladora de software: LIM.DELTA. Esta ejecución tuvo una duración de cinco meses aproximadamente y estuvo siendo monitoreada y guiada bajo el proyecto ProCalProSer. Este ciclo estuvo desplegado en diferentes etapas las cuales dieron como resultados diferentes entregables para satisfacer los objetivos del presente proyecto de fin de carrera. Al inicio del ciclo de mejora, se realizó una evaluación diagnóstica con el fin de medir el grado de adhesión de los procesos de la organización con la norma ISO/IEC 29110. Las preguntas realizadas se basaron en el modelo ISO/IEC 15504. Esta evaluación no requirió de pruebas o evidencias para demostrar la veracidad de las afirmaciones vertidas por los participantes. El informe técnico de la evaluación inicial que se obtuvo satisfizo el objetivo específico número uno. La organización tuvo iniciativas de mejora en un principio por ello adoptó la ISO 9000 para certificar uno de sus productos. Sin embargo, la aspiración que tenían era certificar toda el área de desarrollo. Esa idea se materializó con este primer ciclo de mejora, no obstante, aún hay procesos que necesitan ser optimizados y que podrán ser cubiertos en un segundo ciclo de mejora. Luego de un análisis minucioso de los procesos y de los resultados de la evaluación se pudo obtener un listado de propuestas de mejora para LIM.DELTA. Con la aprobación de la gerencia y con ciertas modificaciones que se tuvieron que realizar, se logró completar un plan de mejora. El plan de mejora de procesos y las propuestas de mejora ajustadas al entorno de la empresa que se elaboraron para la organización satisficieron los objetivos específicos número dos y tres. Al finalizar la ejecución de las mejoras, se logró realizar una evaluación final del ciclo de mejora, se pudo evaluar el esfuerzo invertido en el proyecto y se logró elaborar un informe o reporte técnico final para los interesados. Esta evaluación final tuvo como objetivo medir el grado de cumplimiento de los procesos actuales de la organización con 87 los procesos que la norma ISO 29110 establece dentro del perfil básico e intermedio. El cálculo del esfuerzo invertido fue posible gracias al registro de horas que el tesista estuvo realizando en el cronograma del proyecto. Por otro lado, el reporte técnico final fue completado a través de una plantilla que el proyecto le facilito al tesista. Con estos resultados se pudieron cumplir los objetivos específicos cuatro, cinco y seis. De acuerdo a los resultados obtenidos de la evaluación teórica, la empresa logra alcanzar el nivel uno en los siguientes procesos: Gestión del Portafolio de Proyectos, Gestión de Proyecto e Implementación de Software. Así mismo, se concluye que cuando una empresa está abierta y dispuesta a someterse a la mejora de procesos entonces se obtienen resultados muy productivos. LIM.DELTA logró mejorar sus principales procesos de manera significativa porque no fue reacia al cambio. 5.3 Recomendaciones Se sugiere para el segundo ciclo de mejora, enfocar los esfuerzos en los procesos de Gestión de recursos y Gestión de procesos. Este ’último mejoró gracias al primer ciclo de mejora; sin embargo, no fueron parte de la priorización. Por otro lado, sería bueno que el siguiente tesista planifique capacitaciones en el área de desarrollo ya que este equipo no recibe mucha atención en estos temas. Así mismo, el jefe de proyectos necesita reforzamiento en temas de mantenimiento de software, conceptos del ciclo de vida del software y buenas prácticas de gestión de proyectos. Es aconsejable que durante el siguiente ciclo de mejora se revisen los formatos propuestos ya que estos aún pueden ser mejorados. Todo dependerá del avance que la empresa logre obtener hasta ese entonces. Así mismo, el tesista debería revisar si esos formatos siguieron siendo usados o si fueron mejorados por la empresa. Se recomienda también verificar que los diferentes documentos que elabore LIM.DELTA estén siendo revisados por un segundo ya que la norma exige mucho la revisión de toda documentación que se realiza en cada uno de los procesos. Esto también puesto que durante la ejecución del piloto, las revisiones fueron el “tema del día a día”. También se sugiere revisar la temática de las capacitaciones en el área de desarrollo y la gestión de recursos ya que a estos no se les ha dado mucho importancia. La gente no había sido capacitada por algún tiempo según los registros de recursos humanos. 88 Asimismo, la adquisición de los recursos para sus diferentes proyectos no seguía un proceso formal. Por otro lado, es conveniente que se supervise la utilización de las herramientas que se dejaron en producción en este primer ciclo. Esto con el objetivo de medir la efectividad de las herramientas en el largo plazo. Cabe resaltar, que el siguiente tesista puede encontrar alguna mejora para estas herramientas y enriquecer mejor los procesos de la empresa. La propuesta de estas herramientas fue considerada como una solución inicial o eventual no definitiva que obviamente se espera que la empresa adquiera mejores paquetes de software en el futuro. Finalmente, sería bueno que la organización aumente su equipo de trabajo porque este es muy reducido. Esta desventaja ocasiona que una persona tenga más de tres roles asignados y en consecuencia muchas actividades resulten innecesarias o absurdas, por citar algunos ejemplos, que el jefe de proyectos realice un documento y que él mismo tengo que revisarlo o que el jefe de proyectos proponga recursos para un proyecto y que el mismo tenga que aprobar dichas propuestas. 89 REFERENCIAS BIBLIOGRÁFICAS [1] PROCHILE, «Estudio de Mercado Servicio de la Industria del Software en el Perú,» 2012. [En línea]. Available: http://www.prochile.gob.cl/contactchile/index/wp- content/contact/2012/07/1122.pdf. [Último acceso: 15 abril 2014]. [2] COMEX, «Conocimiento peruano para el Mercado Mundial,» [En línea]. Available: http://www.comexperu.org.pe/archivos%5Crevista%5Cjunio08%5Cespecial130.pdf. . [Último acceso: 15 04 2014]. [3] RPP, «El 90% de empresas desarrolladoras de software son micro y pequeñas”,» 2011. [En línea]. Available: http://www.rpp.com.pe/2011-08-09-el-90-de-empresas- desarrolladoras-de-software-son-micro-y-pequenas-noticia_392626.html. [Último acceso: 10 abril 2014]. [4] ISO 9001, «ISO 9000 essentials,» 2008. [En línea]. Available: http://www.iso.org/iso/iso_catalogue/management_standards/iso_9000_iso_14000/is o_9000_essentials.htm.. [Último acceso: 10 abril 2014]. [5] F. Pino, F. García, F. Ruiz y M. Piattini, Adaptación de las normas ISO/IEC 12207:2002 y ISO/IEC 15504:2003 para la evaluación de la madurez de procesos de software en países en desarrollo, vol. 4, 2006, pp. 17-24. [6] CMMI, «Product Team. CMMI for Development,» Software Engineering Institute, Carnegie Mellon University, 2010. [En línea]. Available: . http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=9661. [7] e. a. De La Villa, «Modelos de Evaluación y Mejora de Procesos: Análisis Comparativo,» 2004. [En línea]. Available: http://www.sc.ehu.es/jiwdocoj/remis/docs/DelaVillaadis2004.doc. [Último acceso: 14 abril 2014]. [8] ISO 12207, «TECNOLOGÍA DE LA INFORMACIÓN. Procesos del Ciclo de Vida del Software,» 2006. [En línea]. Available: http://www.bvindecopi.gob.pe/normas/isoiec12207.pdf. . [Último acceso: 12 abril 2014]. [9] ONGEI-PCM, NTP-ISO/IEC 12207:2004 TECNOLOGÍA DE LA INFORMACIÓN. Procesos del ciclo de vida del software. 1ª Edición. [10] ISO/IEC 15504-2, Information Technology – Process Assessment – Part 3 Guidance on performing an assessment, 2004. [11] T. Olson, L. Parker, J. Mullaney, . Over, N. Reizer, M. Kellner, R. Phillips y S. DiGennaro, A Software Process Framework for the SEI Capability Maturity Model Repeatable Level, Pittsburgh: Carnegie Mellon University, 1993. [12] J. Chirinos, «Evaluacióon de organizaciones software mediante el modelo CMMI». [13] A. Anex, «Gestión por procesos,» 2008. [En línea]. Available: http://www.revistaleadership.com/articulos-colaboradores/effective- management/gestion-por-procesos/. [14] D. B. A. García, «Un enfoque actual sobre la calidad del software,» ACIMED, 1995, pp. 40-42. [15] S. Porta, N. Chávez y Y. Laffita, Indicadores de calidad para software de simulación, Centro de Geoinformática y Señales Digitales y Universidad de las Ciencias Informáticas, 2012. [16] A. Dávila, «VSE Perfil Básico,» [En línea]. Available: http://vse- latino.pucp.pe/vse- 90 iso-iec-29110. [Último acceso: 06 junio 2014]. [17] P. J., «¿Por qué fracasan los proyectos?,» 2008. [En línea]. Available: Www.emb.cl/gerencia/articulo.mvc?xid=1275\. [Último acceso: 14 abril 2014]. [18] W. Deming, Out of the Crisis: Quality, Productivity and Competitive Position, Cambridge University Press, 1986. [19] L. Cuatrecasas Arbós, «Los costos de la calidad y de la no calidad,» [En línea]. [Último acceso: 06 junio 2014]. [20] M. Sullayman y E. Mendes, Quantitative assessments of key success factors in software process improvements for small and medium web companies, New York, 2010, pp. 2319-1323. [21] M. Q. C. R. L. García, «Costo de la calidad y mala calidad,» 2002. [En línea]. Available: http://sisbib.unmsm.edu.pe/bibvirtual/publicaciones/indata/v05_n1/calidad.htm. [Último acceso: 21 marzo 2014]. [22] M. Piattini, Fábricas de Experiencias, Tecnología y OrganizacióN, Alfaomega Editor, 2007. [23] MoProSoft, H. Oktaba, E. Alquicira, A. Su Ramos, A. Martínez, G. Quintanilla, M. Ruvalcaba, F. López, L. Hinojo, M. Rivera, J. Orozco y Y. y. F. M. Fernández, Modelo de Procesos para la industria de Software, 2005. [24] A. Dávila, C. Basurto, L. Flores, R. Manrique, R. Arisaca, J. Sánchez y M. Schneck de Paula Pessôa, The Peruvian Component of Copetisoft Project: Lesson Learned from Academic Perspective.. [25] A. Davila, «ProCal-ProSer,» [En línea]. Available: https://sites.google.com/a/pucp.pe/procal-proser/. [Último acceso: 10 Agosto 2014]. [26] G. Javier, A. De Amescua y M. Velasco, Top 10 de problemas relativos a la mejora del proceso de verificación y validación en organizaciones intensivas en software, Madrid: Pris, 2006. [27] P. Crosby, Quality is free, New York: Mc Graw Hill, 1979. [28] RAE, 2007. [En línea]. Available: http://www.rae.es/rae.html. [Último acceso: 7 abril 2014]. [29] SEI, «What is CMMI?,» 2006. [En línea]. Available: http://www.sei.cmu.edu/cmmi/general/. [Último acceso: 14 abril 2014]. [30] J. Pereiro, «Medición, análisis y mejora – Generalidades,» 2007. [En línea]. Available: http://www.portalcalidad.com/articulos/index.php?storytopic=9&storynum=15. [Último acceso: 12 abril 2014]. [31] NTP-ISO/IEC 12207, Tecnología de la información. Procesos del ciclo de vida del software. 2da Edición-Parte 1 Objeto y Campo de Aplicación, 2006. [32] T. Ventura y M. Peñaloza, MoProSoft: modelo de procesos de software hecho en México, México, 2006. [33] M. Peñaloza, «MoProSoft: modelo de procesos de software hecho en México,» 2006. [En línea]. Available: http://www.enterate.unam.mx/Articulos/2006/marzo/moprosoft.htm. [Último acceso: 14 abril 2014]. [34] L. Guerrero, Ciclo de mejora de procesos: El modelo IDEALSM, Montreal, 1999. [35] SOFTEX, «Guía General 2009,» 2009. [En línea]. Available: 91 http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf. [Último acceso: 15 abril 2014]. [36] G. Santos, M. Kalinowski, A. Regina, K. Chavez y G. Horta, MPS.BR Program and MPS Model: Main Results, Benefits and Beneficiaries of Software Process Improvement in Brazil, Eighth International Conference on the Quality of Information and Communications Technology, 2012. [37] J. d. F. Franciscani y L. Pestili, CMMI e MPS.BR: Um Estudo Comparativo, Revista Rumos, 2012. [38] J. Hurtado, F. Pino, J. Vidal, C. Pardo y L. Fernández, Agile SPI: Software Process Agile Improvement- A colombian Approach to Software Process Improvement in Samll Software Organizations, Software process improvement for small and medium enterprises: techniques and case studies (M. Piattini, Oktaba, H.). Idea Group Inc, 2008. [39] C. Pardo, J. Hurtado y C. Collazos, Mejora de Procesos de Software Ágil con Agile SPI Process, Medellin: Revista Dyna, 2009. [40] C. Pardo, J. Hurtado y A. Collazos, «Mejora de procesos de software ágil con agile - SPI process,» Dyna, 2010, pp. 251-263. [41] M. Piattini, H. Jadwia, M. Orozco y E. Alquicira, Competisoft. Mejora de procesos software para pequeñas y medianas empresas y proyectos, RA-MA EDITORIAL, 2008. [42] COMPETISOFT, «Proyecto de mejora de procesos para fomentar la competitividad de la pequeña y mediana industria del software de Iberoamérica,» 2006. [43] Alarcon Andrea, Gonzales Juan, Rodriguez Sandra, «Guía para Pymes desarrolladora de software, basada en la norma ISO/IEC 15504,» [En línea]. Available: http://revistavirtual.ucn.edu.co/index.php/RevistaUCN/article/viewFile/339/651. [44] H. Oktaba, Software Process Improvement for Small and Medium Enterprises: Techniques and Case Studies: Techniques and Case Studies, IGI Global Editor, 2008. [45] A. Davila, C. Basurto, L. Flores, R. Manrique, A. Robert, J. Sanchez y M. Schneck de Paula, The Peruvian Component of Competisoft Project: Lesson Learned from Academic Perspective, 2012. [46] D. Briceño, Mejora del proceso software de una pequeña empresa desarrolladora de software: Caso competisoft-Perú omega, Lima, 2009. [47] G. Sánchez, Mejora del proceso software de una pequeña empresa desarrolladora de software: Caso competisoft-Perú tau, Lima, 2008. [48] M. Palomino, Mejora del proceso software de una pequeña empresa desarrolladora de software: Caso competisoft-Perú Lim.Lambda, segundo ciclo, Lima, 2011. [49] A. Méndez, Mejora del proceso software de una pequeña empresa desarrolladora de software: Caso competisoft-Perú Lim.omega, primer ciclo, Lima, 2012. [50] B. Rios, M. Vargas, J. Espinoza y M. Peralta, Experiences on the Implementation of MoProSoft and Assessment of Processes under the NMX-I-059/02-NYCE-2005 Standard in a Small Software Development Enterprise, Baja California: ISBN, 2008. [51] G. Cii, «Pruebas controladas de MoProsoft,» 11 11 2005. [En línea]. Available: http://www.gpocii.com/gciimps/frame_seccion.cfm?CVE_SECC=03&CVE_ARTIC ULO=02. [Último acceso: 06 10 2014]. 92 [52] G. Cii, «La mejora de los procesos en México,» 11 12 2005. [En línea]. Available: http://www.gpocii.com/gciimps/frame_seccion.cfm?CVE_SECC=03&CVE_ARTIC ULO=03. [Último acceso: 06 10 2014]. [53] F. Romero y M. Blanco, «Mejoramiento de procesos de software en pequeñas empresas,» 19 01 2008. [En línea]. Available: http://paradigma.uniandes.edu.co/index.php?option=com_content&task=view&id=3 3&Itemid=33&lang=es&showall=1. [Último acceso: 06 10 2014]. [54] J. Garzás y M. Piattini, La Mejora de Procesos en Pequeñas Empresas y la ISO/IEC 29110, 2010. [55] G. De la Incera Torres, «Medidas de calidad en proces, producto y mantenimiento alicadas al cotrol estadístico de procesos,» Escuela Superiro de Informática de la Universidad de Castilla, 2009. [En línea]. Available: http://goo.gl/gWpJF. [Último acceso: 14 abril 2014]. [56] IRAM, «Instituto Argentino de Normalización y Certificación,» 2013. [En línea]. Available: http://www.iram.org.ar. [Último acceso: 17 abril 2014]. [57] M. Staples, M. Niazi, R. Jeffery, A. Abrahams y P. y. M. M. Byatt, «An exploratory study of why organizations do not adopt CMMI,» junio 2007. [En línea]. Available: http://dx.doi.org/10.1016/j.jss.2006.09.008. [Último acceso: 15 abril 2014]. [58] Cámara de Comercio de Lima, 14 03 2014. [En línea]. [59] M. Muñoz, J. Mejía, J. Calvo-Manzano, G. Cuevas y T. San Feliu, Evaluación de los Procesos Software de una Organización Enfocando en la Disminución de la Resistencia al Cambio. [60] «What is a Project management?,» [En línea]. Available: http://whatisprojectmanagement.wordpress.com/2012/11/02/crear- la-edt-del- proyecto/.