PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA MEJORA DE PROCESO SOFTWARE EN UNA PEQUEÑA ORGANIZACIÓN DESARROLLADORA DE SOFTWARE: CASO PROCAL-PROSER- LIM.ALFA – 1ER CICLO Tesis para optar por el Título de Ingeniero Informático, que presenta el bachiller: MANUEL MICHAEL ESCOBEDO TERRAZOS ASESOR: LUIS ALBERTO FLORES GARCIA CO-ASESOR: ABRAHAM ELISEO DAVILA RAMON Lima, Septiembre del 2015 2 RESUMEN Hoy en día la alta competitividad de la industria de software fuerza a las empresas a mejorar continuamente la calidad de los productos que generan. Es en este contexto que muchas pequeñas organizaciones desarrolladoras de software buscan aliviar los problemas que les impiden producir un software de calidad. Entre los principales problemas encontrados tenemos la entrega del producto fuera del tiempo acordado con el cliente y la entrega de un producto con errores. Para solucionar estos problemas, el presente trabajo de fin de carrera consistió en realizar un ciclo de mejora de procesos a una pequeña organización desarrolladora de software. Para la realización de este ciclo, se realizó una evaluación inicial del estado de los procesos de la empresa. Luego, se seleccionaron y se planificó las mejoras a los procesos cuyo impacto de mejora es mayor para la empresa. Posteriormente se realizó una evaluación final para obtener el estado de los procesos de la empresa luego de las mejoras. Finalmente, se generó un reporte técnico para la empresa. Este proyecto se justificó debido a que aporta diversos beneficios a la empresa a la cual se le realizó el ciclo de mejora, lo cual impacta en sus directamente en sus trabajadores y clientes, e indirectamente el los clientes de su cliente. 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 3 A mi padre por inculcar en mí la pasión por las ciencias y la tecnología, a mi hermana por su apoyo y guía durante toda mi carrera y sobre todo a mi madre por todo lo que hiciste y aún haces por mí, les estaré siempre agradecido. 4 AGRADECIMIENTOS Este trabajo ha sido realizado dentro del proyecto ProCal-ProSer (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.) financiado por Innóvate Perú bajo el Contrato 210-FINCYT-IA-2013 y parcialmente soportado por el Departamento de Ingeniería y el Grupo de Investigación y Desarrollo de Ingeniería de Software (GIDIS) de la Pontificia Universidad Católica del Perú. 5 INDICE 1 INTRODUCCIÓN 9 1.1 LA INDUSTRIA DE SOFTWARE EN EL PERÚ ___________________________________ 9 1.2 EL PROYECTO COMPETISOFT EN EL PERÚ ________________________________ 10 1.3 EL PROYECTO PROCAL-PROSER __________________________________________ 11 1.4 EL COMPONENTE MEJORA DE PROCESOS EN DESARROLLO DE SOFTWARE ________ 11 2 PROPUESTA DEL PROYECTO DE TESIS 12 2.1 OBJETIVOS, RESULTADOS Y ALCANCE ______________________________________ 12 2.1.1 OBJETIVO GENERAL ____________________________________________________ 12 2.1.2 OBJETIVOS ESPECÍFICOS ________________________________________________ 12 2.1.3 RESULTADOS _________________________________________________________ 12 2.1.4 ALCANCE ____________________________________________________________ 13 2.2 HERRAMIENTAS, TÉCNICAS Y PROCEDIMIENTO ______________________________ 13 2.3 JUSTIFICACIÓN Y VIABILIDAD DEL PROYECTO _______________________________ 15 2.3.1 JUSTIFICIÓN __________________________________________________________ 15 2.3.2 VIABILIDAD __________________________________________________________ 15 2.4 PLAN DE TRABAJO ______________________________________________________ 15 3 MARCO DE REFERENCIA 17 3.1 MODELOS PARA PROCESO SOFTWARE ______________________________________ 17 3.1.1 MODELOS DE PROCESO _________________________________________________ 17 3.1.2 MODELOS DE MEJORA __________________________________________________ 20 3.1.3 MODELOS DE EVALUACIÓN ______________________________________________ 21 3.2 EXPERIENCIAS DE MEJORA _______________________________________________ 22 3.2.1 TESIS DE COMPETISOFT-PERU ____________________________________________ 22 3.2.2 EXPERIENCIAS DE MOPROSOFT __________________________________________ 23 3.2.3 PROBLEMAS EN MEJORA DE PROCESOS EN PYMES _____________________________ 24 3.3 ISO/IEC 29110 ________________________________________________________ 24 3.3.1 ESTRUCTURA DE LA NORMA _____________________________________________ 24 3.3.2 EL PERFIL BÁSICO _____________________________________________________ 25 3.3.3 EL PERFIL ORGANIZACIONAL (DRAFT DE LA ISO) _____________________________ 28 4 MEJORA DEL PROCESO 29 4.1 DESCRIPCIÓN DE LA EMPRESA ____________________________________________ 29 4.2 EVALUACIÓN DIAGNÓSTICA DE LA EMPRESA ________________________________ 30 4.2.1 OBJETIVO DE LA EVALUACIÓN____________________________________________ 31 4.2.2 OBJETIVOS DE LA EMPRESA ______________________________________________ 31 4.2.3 PROBLEMAS DE LA EMPRESA _____________________________________________ 31 4.2.4 PROCESOS A SER EVALUADOS ____________________________________________ 32 4.2.5 PERFIL DE CAPACIDADES ________________________________________________ 32 4.2.6 RESULTADOS OBTENIDOS _______________________________________________ 35 4.3 PLAN DE MEJORA DE PROCESOS ___________________________________________ 44 4.3.1 IDENTIFICACIÓN DE PROCESOS PARA EL CICLO DE MEJORA _____________________ 44 4.3.2 PROPUESTA DE PLAN DE MEJORA _________________________________________ 51 4.4 EJECUCIÓN DE LAS MEJORAS _____________________________________________ 60 4.4.1 GESTIÓN DE PROYECTO _________________________________________________ 60 4.4.2 IMPLEMENTACIÓN DE SOFTWARE _________________________________________ 67 4.4.3 GESTIÓN DE PORTAFOLIO DE PROYECTO ___________________________________ 73 4.5 EVALUACIÓN DE MEJORAS INTRODUCIDAS __________________________________ 73 4.6 PROBLEMAS IDENTIFICADOS Y ACCIONES TOMADAS __________________________ 76 6 5 OBSERVACIONES, CONCLUSIONES Y MEJORA 78 5.1 OBSERVACIONES _______________________________________________________ 78 5.2 CONCLUSIONES ________________________________________________________ 78 5.3 RECOMENDACIONES ____________________________________________________ 79 6 BIBLIOGRAFÍA 80 7 INDICE DE FIGURAS Figure 3.1Diagrama de categorías de procesos. ________________________________ 19 Figure 3.2Modelo de evaluación de Competisoft ________________________________ 21 Figure 3.3Niveles de Madurez ISO/IEC 15504 __________________________________ 22 Figure 3.4Formato de la norma ISO/IEC 29110 _________________________________ 25 Figure 3.5 Perfil básico de la ISO/IEC 29110-5-1-2:2011 _________________________ 26 Figure 3.6 Proceso de Gestión de Proyecto de la ISO/IEC 29110-5-1-2:2011 _________ 26 Figure 3.7 Proceso de Implementación de Software de la ISO/IEC 29110-5-1-2:2011 ___ 27 Figure 4.1 Organigrama Lim.Alfa ____________________________________________ 29 Figure 4.2 Perfil de Capacidad de Procesos Final _______________________________ 34 Figure 4.3 Distribución de cumplimiento del Proceso Gestión de Proyecto ____________ 36 Figure 4.4 Distribución de cumplimiento del Proceso Implementación de Software _____ 38 Figure 4.5 Distribución de cumplimiento del Proceso Gestión de Recursos ___________ 40 Figure 4.6 Distribución de cumplimiento del Proceso Gestión de Procesos ________ 42 Figure 4.7 Distribución de cumplimiento del Proceso Gestión de Portafolio de Proyectos 43 Figure 4.8 Diagrama de Evaluación de Impacto. ________________________________ 48 Figure 4.9 Diagrama de Impactos de Procesos. _________________________________ 50 Figure 4.10 Proceso Gestión de Proyecto Inicial. ________________________________ 55 Figure 4.11 Proceso Implementación de Software Inicial. _________________________ 59 8 INDICE DE TABLAS Table 2.1 Herramientas utilizadas. ___________________________________________ 14 Table 4.1 Valores de Niveles de Cumplimiento. _________________________________ 33 Table 4.2 Grados de cumplimientos ISO/IEC 29110 ______________________________ 34 Table 4.3 Escala de Impacto. ________________________________________________ 45 Table 4.4 Priorización de Objetivos de Negocio _________________________________ 46 Table 4.5 Priorización de Problemas. _________________________________________ 46 Table 4.6 Objetivos de Negocio vs Problemas de Negocio. ________________________ 47 Table 4.7 Priorización de Procesos. __________________________________________ 49 Table 4.8 Roles Proceso Gestión de Proyecto. __________________________________ 52 Table 4.9 Proceso Gestión de Proyecto inicial __________________________________ 54 Table 4.10 Roles Proceso Implementación de Software ___________________________ 57 Table 4.11 Proceso Implementación de Software inicial ___________________________ 58 Table 4.12 Definición del Proceso Gestión de Proyecto ___________________________ 63 Table 4.13 Entradas al Proceso Gestión de Proyecto. ____________________________ 63 Table 4.14 Salidas al Proceso Gestión de Proyecto. ______________________________ 63 Table 4.15 Productos internos del Proceso Gestión de Proyecto. ___________________ 64 Table 4.16 Roles del Proceso Gestión de Proyecto. ______________________________ 64 Table 4.17 Actividades del Proceso Gestión de Proyecto. _________________________ 66 Table 4.18 Definición del Proceso Implementacón de Software. ____________________ 69 Table 4.19 Entradas al Proceso Implementación de Software. ______________________ 70 Table 4.20 Salidas al Proceso Implementación de Software. _______________________ 70 Table 4.21 Roles del Proceso Implementación de Software. ________________________ 70 Table 4.22 Actividades del Proceso Implementación de Software. ___________________ 73 Table 4.23 Nivel de Cumplimiento de Procesos Final _____________________________ 74 Table 4.24 Logros del Ciclo de Mejora según Objetivos de Mejora. _________________ 75 Table 4.25 Problemas identificados y Acciones tomadas __________________________ 77 9 1 Introducción La mejora de procesos es un camino interesante. En particular en esta sección se presenta la realidad para la industria de software a nivel mundial, la realidad de la industria de software en el Perú, algunos de los proyectos que han sido realizados en este contexto y la razón porque es importante la realización de mejoras a los procesos de desarrollo de software. 1.1 La industria de software en el Perú En los últimos años, se ha vuelto una necesidad para toda empresa el uso de las tecnologías de la información. Debido a ello la industria de desarrollo de software ha sufrido un alto crecimiento [MEJORA2002]. En particular, en el Perú, se puede observar que estos productores de software tienen una alta presencia en los diferentes sectores de nuestra economía [APESOFT2014]. En nuestro país más del 98% de las empresas son micro y pequeña empresa (MYPE), y brindan empleo a alrededor de 60% de la fuerza laboral del Perú [PROD2011]. Además, las MYPE se encuentran presentes en la mayor parte de los sectores de nuestra economía. Debido a esto es que estas empresas son consideradas un factor muy importante en el desarrollo del país. Si bien la MYPE es pequeña comparada con sus equivalentes en Colombia, México, Argentina y Chile, la inversión realizada en los últimos 4 años es la que posee una mayor tasa de crecimiento acumulado [PCHILE2013]. Debido a estas condiciones de nuestra economía, al crecimiento de la demanda de soluciones de software y a que las micro y pequeñas empresas desarrolladoras de software son las encargadas de generar el software de muchas empresas medianas y grandes; es que las empresas desarrolladoras de software deben ser consideradas un factor importante en nuestro país. Para poder cubrir el crecimiento de la demanda de software en nuestro país, las empresas desarrolladoras de software han sufrido un crecimiento considerable. Pero muchos de los procesos con los que cuentan estas empresas no se encuentran debidamente desarrollados para sus nuevas situaciones. Este contexto genera diversos problemas, entre los cuales los más importantes son:  Estas empresas cuentan con baja productividad. 10  Los productos software generados poseen una alta tasa de defectos.  Se generan incumplimientos en los plazos y presupuestos establecidos para el desarrollo del software. Una de las razones por las que estos problemas son generados es debido a que los procesos de desarrollo de las empresas no permiten generar sus productos software de una manera eficiente. Las empresas desarrolladoras no pueden garantizar la generación de un software de calidad, lo que genera malestar a las empresas que contrataron su servicio. En la actualidad existen diversos modelos como es el caso del CMMI, que es un modelo de madurez para la mejora y la evaluación de procesos de software y la ISO/IEC 12207:2008, que es un estándar de referencia para todo el ciclo de vida del software; sin embargo, estos modelos no fueron diseñados para pequeñas empresas y su adopción conlleva un alto costo económico y un gran esfuerzo técnico que las pequeñas organizaciones (PO) no pueden afrontar. 1.2 El proyecto COMPETISOFT en el Perú El proyecto COMPETISOFT fue una iniciativa desarrollada en todo Iberoamérica que utilizó como base MoProSoft, EvalProSoft y agile SPI para generar su propio modelo de mejora de procesos [IEEE2007]. Este proyecto buscó desarrollar un marco metodológico común para lograr incrementar el nivel de competitividad de las PyMEs iberoamericanas productoras de software. En el Perú el proyecto COMPETISOFT fue desarrollado en su primera fase por la Pontificia Universidad Católica del Perú. Luego se desarrolló el proyecto COMPETISOFT-PUCP, que al igual que COMPETISOFT contó con los siguientes 3 componentes:  Procesos de mejora en empresas: En este componente un grupo de miembros del proyecto realizaron mejoras a los procesos de desarrollo de software de diversas empresas con el fin de mejorar su productividad. 11  Construcción de herramienta de Gestión de procesos de software: En este componente se buscó crear una herramienta basada en lenguajes de definición de procesos con el fin de dar soporte a la mejora de la gestión de procesos, metodologías y sus evoluciones en las empresas.  Mapeo de modelos de procesos: En este componente se determinó la correspondencia del modelo creado en el proyecto con otros modelos reconocidos internacionalmente para asi determinar la alineación con los mismos. 1.3 El proyecto ProCal-ProSer El proyecto ProCal-ProSer (Productividad y Calidad en Productos software y Servicios software) es una iniciativa que busca determinar los factores que intervienen en la mejora de procesos de organizaciones que desarrollan productos software y ofrecen servicios software usando como referencia normas ISO/IEC [PCPS2014]. Este proyecto es desarrollado por el Grupo de Investigación y Desarrollo en Ingeniería de Software de la PUCP (GIDIS-PUCP), con participación de la Universidad Nacional de San Agustín, Universidad Privada del Norte, la Escuela Politécnica de la Universidad de Sao Paulo y la Asociación de Productores de Software (APESOFT). Las actividades desarrolladas en el proyecto se encuentran financiadas por el Fondo para la Innovación, Ciencia y Tecnología (FINCyT), cuya fecha de inicio fue el año 2013 y su fecha de culminación es en Diciembre del 2016. 1.4 El componente mejora de procesos en desarrollo de software Los procesos de desarrollo de software son procesos que varían en cada organización y son influenciados por las características propias de la organización y por su entorno. Es por esto que mientras existan cambios, ya sean internos o externos a la organización, los procesos de desarrollo de software van a tener que adecuarse a estos. 12 Es en este sentido que los procesos de desarrollo de software deben lograr ubicarse en una situación en la cual se esté realizando periódicamente ciclos de mejora continua. 2 Propuesta del proyecto de tesis En este punto se describen los objetivos que se buscan lograr con el proyecto, los resultados que se esperan obtener y las herramientas que servirán de ayuda a lograr estos objetivos. 2.1 Objetivos, resultados y alcance A continuación se indican los objetivos, resultados y el alcance del presente proyecto de tesis: 2.1.1 Objetivo general Realizar el primer ciclo de mejora de procesos en una organización desarrolladora de software dentro del marco del proyecto ProCal-ProSer. 2.1.2 Objetivos específicos Los objetivos específicos (OE) del presente proyecto son:  OE1: Determinar la situación inicial de la organización.  OE2: Realizar la planificación de la mejora en los procesos seleccionados.  OE3: Ejecutar el ciclo de mejora de acuerdo al plan establecido.  OE4: Determinar la situación al final del ciclo de mejora.  OE5: Elaborar el reporte técnico correspondiente. 2.1.3 Resultados Para obtener el cumplimiento de los objetivos anteriormente planteados se debe obtener los siguientes resultados:  Resultado 1 (OE1): Obtener un informe con la caracterización de la situación actual de la organización.  Resultado 2 (OE2): Obtener un plan para la implementación de las mejoras de los procesos de la organización.  Resultado 3 (OE3): Obtener una lista de puntos desarrollados durante la implementación. 13  Resultado 4 (OE4): Obtener un informe que contenga una evaluación de la situación final de la organización.  Resultado 5 (OE5): Obtener un reporte técnico que contenga la evaluación del ciclo de mejora y las directrices para un nuevo ciclo de mejora. 2.1.4 Alcance El primer ciclo de proceso de mejora se aplicará a una pequeña organización desarrolladora de software comprometida con el Proyecto. La organización será referida como LIM.ALFA de una lista mayor de empresas participantes para mantener su confidencialidad. Este proyecto cubre desde el análisis de la situación actual y finaliza con el reporte técnico sobre la evaluación del ciclo de mejora desarrollado, esto incluye la evaluación del ciclo de mejora realizado y las directrices para iniciar un nuevo ciclo de mejora. Adicionalmente se presentan las lecciones aprendidas en el proceso de mejora seguido y la evaluación del esfuerzo desarrollado en la mejora de procesos. Para la selección de los procesos a mejorar se tomó como referencia la ISO/IEC 29110-5-1-2:2011 que corresponde al Perfil Básico (Gestión de Proyectos e Implementación de Software) y el borrador de la ISO/IEC FDIS 29110-5-1-3 que corresponde al Perfil Intermedio (Gestión de Recursos, Gestión de Procesos y Gestión de Portafolio de Proyectos). 2.2 Herramientas, técnicas y procedimiento En el presente punto se detallan las herramientas, métodos y procedimientos que se utilizarán durante el desarrollo del proyecto. A continuación se muestran las herramientas asociadas a cada resultado esperado (RE): Resultado esperado Herramienta a utilizarse RE1: Obtener un informe con la caracterización de la situación actual de la organización. NTP ISO/IEC 29110-5-1-2:2011. ISO/IEC FDIS 29110-5-1-3. Microsoft Word. RE2: Obtener un plan para la implementación de las mejoras de los procesos de la organización. Business Process Modeling Notation (BPMN), Bizagi Process Modeler. ISO/IEC 15504-2:2004 Microsoft Word. 14 Resultado esperado Herramienta a utilizarse RE3: Obtener una lista de puntos desarrollados durante la implementación. NTP ISO/IEC 29110-5-1-2:2011. MoProSoft. Web2Project. Microsoft Word. RE4: Obtener un informe que contenga una evaluación de la situación final de la organización. NTP ISO/IEC 29110-5-1-2:2011. ISO/IEC FDIS 29110-5-1-3 RE5: Obtener un reporte técnico que contenga la evaluación del ciclo de mejora y las directrices para un nuevo ciclo de mejora. NTP ISO/IEC 29110-5-1-2:2011. Microsoft Excel. Table 2.1 Herramientas utilizadas. [Elaboración Propia] A continuación se muestra una breve descripción de las herramientas utilizadas para el logro de los resultados esperados.  Bizagi Process Modeler: Herramienta para el modelado de procesos empresariales basada en BPMN [BIZAGI]. Se utilizó para elaborar los documentos que mostrarán los procesos de negocio seleccionados.  NTP ISO/IEC 29110-5-1-2: Perfil básico de la NTP ISO/IEC 29110 que fue utilizada como herramienta para la elaboración del plan de mejora a desarrollar.  NTP ISO/IEC 15504-2: Norma internacional utilizada como herramienta para evaluar los procesos de la empresa durante el análisis de los mismos.  Web2Project: Herramienta de código abierto para gestionar proyectos utilizada para gestionar el ciclo de mejora dentro de la empresa. También se utilizó BPMN (Business Process Model and Notation), Notación gráfica estandarizada para el modelado de procesos que es utilizada para crear una conexión entre el diseño de procesos y su implementación [BPMN2011]. 15 2.3 Justificación y viabilidad del proyecto En este punto se detallan las razones y viabilidad de realizar el presente proyecto. 2.3.1 Justificación La realización del presente proyecto de tesis es conveniente debido a que permitirá elevar la capacidad de procesos para el desarrollo de software en la empresa. Los principales beneficiarios de la ejecución de este proyecto son la empresa de estudio, a la que se le realizará el ciclo de mejora, y los clientes de esta empresa que obtendrán probablemente un producto software de mejor calidad. Además, este proyecto puede ser utilizado por otras empresas como un ejemplo de aplicación de un ciclo de mejora de procesos. 2.3.2 Viabilidad Se han analizado los siguientes criterios para probar la viabilidad del proyecto:  Viabilidad de recursos: Los recursos serán proporcionados por la empresa a la cual se le realizarán las mejoras de sus procesos. Estos recursos comprenden tanto personal como la información de los procesos.  Viabilidad de herramientas: Las herramientas a utilizar no generan un mayor riesgo al desarrollo del proyecto, debido a que pueden ser obtenidas de manera gratuita o no poseen un alto costo. 2.4 Plan de trabajo El plan de trabajo utilizado para implementar el ciclo de mejora en la empresa dentro del contexto del presente proyecto de tesis ha sido realizado siguiendo las siguientes etapas:  Inducción: Etapa de relevamiento de información de la empresa y conocimiento de la misma.  Diagnóstico: Evaluación de la situación actual de los procesos de la empresa.  Selección de procesos de mejora: Selección de los procesos a ser mejorados y la elaboración del Plan de Mejora de estos. 16  Gestionar la mejora de procesos: Implantación del Plan de Mejora.  Cierre del proyecto: Realizar la evaluación final de la empresa, preparar y entregar informes del proyecto. 17 3 Marco de referencia 3.1 Modelos para proceso software 3.1.1 Modelos de proceso Es un conjunto de procesos estructurados de manera lógica que permite tener una perspectiva de las prácticas que deben ser realizadas para poder obtener los resultados esperados. En la actualidad existen diversos modelos que nos ayudan a conocer el nivel de madurez de los procesos de una organización desarrolladora de software. Entre estos tenemos al CMMI, ISO 9001:2008, ISO/IEC 12207:2006, MoProSoft, MPS.BR, entre otros. 3.1.1.1 CMMI Capability Maturity Model Integration (CMMI) es uno de los modelos más populares en todo el mundo, usado en 94 países y disponible en 10 lenguajes distintos [CMMIINST]. Fue desarrollado por el Software Engineering Institute (SEI) a pedido del departamento de defensa de los Estados Unidos de América [SEI2014]. Este es un modelo de mejora de procesos que engloba un conjunto de buenas prácticas para el desarrollo y mantenimiento de productos, cubriendo el ciclo de vida completo de estos [CMMI2014]. Según el CMMI institute, CMMI soporta dos enfoques de mejora de procesos [CMMIINST]:  Representación Continua: Este enfoque busca realizar mejoras incrementales a un área de proceso determinada por la organización.  Representación Escalonada: Este enfoque busca mejorar los resultados de una empresa mediante las prácticas para un conjunto de áreas de proceso relacionadas. A continuación se presentan los beneficios que pueden ser obtenidos con una implantación de CMMI son los siguientes [CMMI2014]: 18  Mejora de la calidad  Incremento de la productividad  Incremento de la satisfacción del cliente  Reducción en el costo de calidad  Mejora en horario y predicción de presupuestos  Incremento en el retorno de la inversión Como se puede observar, implantar el enfoque CMMI presenta beneficios muy importantes para el desarrollo de una empresa. 3.1.1.2 NTP-ISO/IEC 12207:2006 Esta norma establece un marco de referencia para los procesos de ciclo de vida del software [ISO12207]. También contiene procesos, actividades y tareas que pueden ser aplicadas durante la adquisición de un sistema de software y durante el suministro del mismo [ISO12207]. Para este propósito, se han logrado agrupar los procesos en tres grupos:  Procesos principales: Estos procesos son cinco y son los encargados de brindar servicio a los procesos básicos del ciclo de vida del software.  Procesos de apoyo: Estos procesos son ocho y están encargados de brindar apoyo a otros procesos según las necesidades: Documentación, gestión de la configuración, aseguramiento de la calidad, entre otros.  Procesos organizativos: Estos procesos son cuatro y su principal objetivo es el brindar una estructura a los procesos del ciclo de vida del software. 3.1.1.3 MoProSoft Modelo de Procesos Software (MoProSoft) es un modelo utilizado para la mejora y evaluación de procesos de desarrollo software. Fue desarrollado para la industria mexicana a solicitud de la Secretaría de Economía del mismo país [MPS2005]. El objetivo de este modelo es lograr elevar la capacidad de las organizaciones para poder servicios de calidad alcanzando niveles internacionales de competitividad [MPS2005]. 19 Según Hanna Oktaba, MoProSoft se encuentra dividido en tres categorías que Agrupan las actividades [MPS2005]: Figure 3.1Diagrama de categorías de procesos. [MPS2005]  La categoría de alta dirección se encarga de apoyar con las actividades que están relacionadas con la gestión del negocio.  La categoría de gestión se encarga de realizar las actividades que apoyen y soporten a los demás procesos del modelo.  La categoría de operación se encarga de realizar las actividades productivas de la empresa, es la que genera valor para esta. En estas categorías se encuentran distribuidos todos los procesos de la organización de manera adecuada para el control de los mismos. 3.1.1.4 ISO/IEC 29110 Norma internacional desarrollada en conjunto por las organizaciones de normalización ISO e IEC. Esta norma define los perfiles de ciclo de vida para pequeñas organizaciones con la finalidad de mejorar la calidad de los productos y servicios generados por estas [ISO29110]. Entre los puntos que desarrolla esta norma tenemos los siguientes [ISO29110]: 20  Parte 3: Se detalla la guía de evaluación de capacidades de los procesos de una organización en relación a los perfiles descritos en la presente norma.  Parte 5-1-2: Se detalla la guía de gestión e ingeniería del grupo de perfil genérico, perfil básico. Esto se realiza a través de los procesos de Gestión del Proyecto e Implementación de Software. Los beneficios que se pueden obtener de utilizar la norma, son los siguientes [NTP29110]:  Poseer un proceso de gestión del proyecto adecuado que permite visualizar desviaciones y realizar acciones correctivas a este.  Poseer un proceso de implementación de software que permita asegurar la calidad de los productos generados. 3.1.2 Modelos de mejora Estos modelos indican una orientación para poder desarrollar procesos adecuados que contribuyan a incrementar el nivel de satisfacción de los clientes al permitir brindarles productos software de calidad. 3.1.2.1 COMPETISOFT Este modelo fue desarrollado en el contexto del proyecto COMPETISOFT y ha tomado los siguientes modelos como referencia para su desarrollo:  MoProSoft: Modelo mexicano desarrollado para pequeñas empresas utilizando como base las mejores prácticas internacionales para el desarrollo de software.  Agile SPI: Es el resultado del enfoque colombiano a la mejora de procesos de desarrollo de software en pequeñas organizaciones.  La metodología española Métrica v3: Es una metodología de planificación, desarrollo y mantenimiento de sistemas de información desarrollada por el Ministerio de Administraciones Públicas de España. El Modelo de Referencia de Procesos de Competisoft establece tres categorías: 21  Alta Dirección(DIR)  Gerencia(GER)  Operación(OPE) Este modelo también cuenta con 5 niveles de madurez para los procesos:  Optimizado  Predecible  Establecido  Gestionado  Realizado A continuación la figura 3.2 muestra las tres categorías de Competisoft así como los procesos que estas poseen. Figure 3.2Modelo de evaluación de Competisoft [IEEE2007] 3.1.3 Modelos de evaluación Estos modelos permiten evaluar las tareas y actividades desarrolladas en los procesos tomando como base ciertos lineamientos particulares de cada modelo. 22 3.1.3.1 ISO/IEC 15504 En una norma internacional madurez de los mismos. las mismas. Figure 3.3Niveles de Madurez ISO/IEC 15504[KyB2014] 3.2 Experiencias de mejora A continuación se detallan diversas experiencias a la mejora de procesos realizadas en ámbitos similares al desarrollado en el presente proyecto. 3.2.1 Tesis de competisoft-peru - 23 liderado por el Grup A continuación se indican los 3 componentes que fueron parte de la realización de estos proyectos:  Procesos de Mejora de una organización Este componente fue desarrollado por un conjunto de integrantes, entre alumnos y egresados de diferentes universidades, con el objetivo de mejorar la productividad de los procesos de desarrollo de software en pequeñas y medianas empresas.  Mapeo de Modelos de Procesos Este componente fue desarrollado por un conjunto de integrantes, entre alumnos y egresados de la Pontificia Universidad Católica del Perú, con el objetivo de determinar el grado en que el modelo pmCOMPETISOFT se alinea a los modelos ya existentes. Para este trabajo se realizaron evaluaciones teóricas para medir la capacidad de procesos usando la norma ISO/IEC 15504.  Construcción de una herramienta de Gestión de Procesos de Software Este componente fue desarrollado por un conjunto de integrantes, entre alumnos y egresados de diferentes universidades, con el objetivo de mejorar la gestión de procesos, metodologías y las evoluciones de estas en las organizaciones del proyecto. Esto se desarrolló utilizando lenguajes de definición de procesos a través de una plataforma virtual. 3.2.2 Experiencias de MoProSoft MoProSoft es un modelo de Software que fue desarrollado para la industria Mexicana. Este modelo toma como referencias las mejores prácticas de la industria, como CMMI e ISO 9001. Debido al éxito de este modelo, este fue utilizado como base para la realización de la ISO/IEC 29110. 24 3.2.3 Problemas en mejora de procesos en pymes Debido a la forma de trabajo de las Pymes, cuando se desea implementar mejoras de procesos en estas surgen diferentes problemas. Estos se encuentran relacionados a la forma de trabajo de estas empresas, muchas veces no existen procesos formales por lo que resulta complicado realizar una mejora a procesos no definidos. En muchos casos, estas empresas no poseen documentación de sus procesos o de poseerla comúnmente no son una imagen fiel de lo que sucede en la realidad de la empresa. Otro problema principal con el que cuentan estas empresas es que en su mayoría no siguen ningún marco de trabajo o algún estándar para verificar que la forma en la que desarrollan su negocio sea la más adecuada, ni tampoco cuentan con un plan estratégico que les ayude a poder definir qué acciones tomar para poder lograr sus objetivos. 3.3 La ISO/IEC 29110 Es una norma internacional desarrollada en conjunto por las organizaciones de normalización ISO e IEC. Esta norma define los perfiles de ciclo de vida para pequeñas organizaciones con la finalidad de mejorar la calidad de los productos y servicios generados por estas. 3.3.1 Estructura de la norma La norma ISO/IEC 29110 se encuentra estructurada en un conjunto de 5 partes. Estas son mostradas en la Figura 3.4: 25 Figure 3.4Formato de la norma ISO/IEC 29110[ISO29110] El formato de la parte 4 es de la forma 29110-4-m, esto debido a que esta parte indica un Grupo de perfil. Para el caso del presente proyecto se utilizó la 29110-4-1 que son las Especificaciones del perfil: Grupo de perfil genérico. En la parte 5 encontramos que el formato de la forma es 29110-m-n, esto debido a que en esta parte se indica la guía de gestión e ingeniería. Para el proyecto realizado se han utilizado la Parte 5-1-2: Guía de gestión e ingeniería: Grupo del perfil genérico: Perfil básico y la Parte 5-1-3: Guía de gestión e ingeniería: Grupo del perfil genérico: Perfil organizacional. 3.3.2 El perfil básico Esta guía proporciona los procesos de Gestión de Proyecto e Implementación de Software, utilizando buenas prácticas obtenidas de la ISO/IEC 12207:2008 y la ISO/IEC 15289:2006. En la Figura 3.5 se muestra la relación que estos procesos poseen en este perfil: 26 Figure 3.5 Perfil básico de la ISO/IEC 29110-5-1-2:2011 [ISO29110] El proceso de Gestión de Proyecto tiene como propósito el establecer y llevar a cabo de manera sistemática las tareas del proyecto de implementación de Software buscando cumplir con los objetivos del proyecto con la calidad, el tiempo y el costo esperados [ISO 29110]. Figure 3.6 Proceso de Gestión de Proyecto de la ISO/IEC 29110-5-1-2:2011 [ISO29110] 27 En la Figura 3.6 se muestra los documentos del proceso de Gestión de Proyecto de la ISO/IEC 29110-5-1-2:2011 y los flujos de estos documentos entre las diferentes actividades de este proceso. El proceso de Implementación de Software tiene como propósito el establecer la reaización sistemática de las actividades de análisis, contrucción, diseño, integración y pruebas para los productos software tomando como base los requisitos especificados. [ISO29110] Figure 3.7 Proceso de Implementación de Software de la ISO/IEC 29110-5-1-2:2011 [ISO29110] 28 En la Figura 3.7 se muestra los documentos del proceso de Implementación de Software de la ISO/IEC 29110-5-1-2:2011 y los flujos de estos documentos entre las diferentes actividades de este proceso. 3.3.3 El perfil organizacional (draft de la ISO) Esta guía aún se encuentra en proceso de desarrollo y viene siendo desarrollada por un comité técnico de la International Organization for Standardization y es recomendada para pequeñas organizaciones que ya han implementado la ISO/IEC 29110 5-1-2:2011: Guía de gestión e ingeniería: Grupo del perfil genérico: Perfil básico. Esta guía se enfoca en los procesos de Gestión de portafolio, Gestión de recursos y Gestión de procesos. Los objetivos de estos procesos son los siguientes[ISO3]:  Gestión de Portafolio: Tiene como propósito generar proyectos para la organización, proveer el contenido técnico necesario para el establecimiento de acuerdos formales de los proyectos, supervisando su desempeño mientras se monitorea la satisfacción del cliente.  Gestión de Recursos: Su propósito es obtener y proveer a la organización con los recursos necesarios para su funcionamiento.  Gestión de Procesos: Su propósito es establecer y mejorar continuamente los procesos de la organización. 29 4 Mejora del proceso A continuación se indican los resultados y el proceso que se siguió al momento de desarrollar la implementación del ciclo de mejora en la empresa Lim.Alfa. 4.1 Descripción de la empresa La empresa Lim.Alfa cuenta con dos Sistemas Integrados especializados para un sector específico, estos son sus actuales productos bandera y principales generadores de ingresos. Los clientes de la empresa se encuentran regulados por una autoridad nacional. Estos deben cumplir la normativa que afecta a este sector por lo que los productos desarrollados por la empresa Lim.Alfa para deben estar alineados a las regulaciones que indica este entidad. Lim.Alfa es una empresa que fue fundada en el año 2003 con el propósito de brindar soluciones de software a un tipo especial de organización dentro de un sector específico.La estructura organizacional al inicio del proyecto de mejora se encuentra conformada por 7 personas y es la presentada en la Figura 4.1: Figure 4.1 Organigrama Lim.Alfa [Elaboración Propia] 30 De esta figura se debe señalar que las áreas de Asesoría Legal y Asesoría Contable son estudios externos a la empresa que brindan servicios a la misma. Además, algunas personas de la organización vienen realizando las funciones de más de un solo cargo. La empresa cuenta con dos tipos de proyectos que pueden ser divididos por la documentación formal que generan para su ejecución:  Proyectos Grandes: En general, estos proyectos tienen una duración de 3 meses a más, se caracterizan porque poseen un Plan de Proyecto, Lista de Requerimientos, Plan de Pruebas, entre otros documentos. Para este tipo de proyectos la empresa realiza la contratación de un Gestor de Proyecto durante la ejecución del proyecto.  Proyectos Pequeños: Este tipo de proyectos suelen tener una duración menor a 3 meses y se caracterizan porque generalmente consisten en la generación de funcionalidades personalizadas a uno de los Sistemas integrados que la empresa posee. Durante el proceso de realización del ciclo de mejora de procesos en la empresa Lim.Alfa la gerencia de la empresa decidió que los procesos a los cuales se les iba a realizar el ciclo de mejora eran a los que se encontraban relacionados con los proyectos pequeños. Esto debido a que los proyectos pequeños son los que realizan con mayor frecuencia y son a los que impactaría más la realización de un ciclo de mejora de procesos. 4.2 Evaluación diagnóstica de la empresa Como parte del proceso de implementación de un ciclo de mejora de procesos en la empresa Lim.Alfa, se realizó una evaluación inicial de los procesos de la empresa para así conocer el grado de cumplimiento de los mismos con la norma ISO/IEC 29110, en específico el perfil básico y el perfil organizacional de la misma. El proceso seguido para el desarrollo de la evaluación fue a través de entrevistas con el Gerente General, Gestor de Proyecto y desarrolladores de la empresa y la revisión de los documentos generados en dos proyectos representativos de la empresa. Este 31 proceso de evaluación fue realizado por un evaluador del proyecto ProCal-ProSer y el tesista que se encuentra implementando el ciclo de mejora en la empresa. 4.2.1 Objetivo de la evaluación Los resultados obtenidos de la evaluación diagnóstica a la empresa fueron utilizados para determinar el perfil de capacidad de los procesos de la organización al inicio del proyecto y así poder diseñar el plan de mejora para el proyecto. La metodología de evaluación utilizada fue la ISO/IEC 15504-2:2003 tomando como modelo de referencia la ISO/IEC 29110-5-1-2:2011 y el borrador del perfil intermedio de la ISO/IEC 29110. 4.2.2 Objetivos de la empresa Una parte fundamental del proceso de inducción en la empresa fue la del levantamiento de información, en la cual se determinaron los objetivos de negocio de Lim.Alfa. Estos objetivos de negocio no se encontraban establecidos de manera formal, por lo que se realizaron un conjunto de comunicaciones con la gerencia y revisiones de ejemplos de objetivos de negocio y es en base a esto que la gerencia identificó que deseba lograr los siguientes objetivos en el plazo de 1 año:  Incrementar los ingresos de la empresa en un 25%.  Mejorar en innovar en el 50% de los procesos utilizados en el core del negocio.  Disminuir en 10% el número de incidentes reportados por los clientes.  Disminuir en 10% el tiempo de respuesta de las solicitudes de atención generadas por los clientes. 4.2.3 Problemas de la empresa Durante el proceso de inducción en la empresa se encontraron diversos problemas, entre estos problemas encontrados se tienen:  Falta de compromiso de los miembros de los equipos con los proyectos desarrollados.  Los tiempos y costos reales de los proyectos no pueden ser calculados.  Falta de estandarización en los documentos generados por la empresa durante el desarrollo de sus proyectos. 32  La calidad de los entregables generados durante el desarrollo de los proyectos no es muy alta.  Falta de supervisión y control de las tareas desarrolladas dentro de los proyectos.  Formalmente no existe un plan estratégico por lo que no se pueden enfocar los esfuerzos de la empresa eficientemente al logro de sus objetivos de negocio. 4.2.4 Procesos a ser evaluados En la evaluación diagnóstica de la empresa Lim.Alfa se consideró evaluar los 2 procesos del perfil básico de la ISO/IEC 29110-5-1-2:2011 y los 3 procesos del perfil intermedio de la misma norma. Por lo que en total se evaluaron los siguientes procesos: Perfil básico:  Gestión de proyecto (PM: Project Management)  Implementación de Software (SI: Software Implementation) Perfil Intermedio:  Gestión de portafolio (PPM: Project Portfolio Management)  Gestión de recursos (RM: Resource Management)  Gestión de procesos (PSM: Processes Management) 4.2.5 Perfil de capacidades El paso siguiente a la evaluación de la empresa fue determinar el perfil de capacidades y el grado de cumplimiento de los procesos de la empresa Lim.Alfa utilizando la ISO/IEC 15504-2:2003 y tomando como modelo de referencia la ISO/IEC 29110-5-1-2:2011 y el draft del perfil intermedio de la ISO/IEC 29110. Para esto se generó un documento que contenía la planificación de la evaluación inicial de los procesos de la empresa. Ver Anexo 4.1 DOC_Plan Evaluación de Procesos Inicial 33 La evaluación de cada proceso ha sido desarrollada utilizando los siguientes niveles de cumplimiento de acuerdo a la ISO/IEC 15504-2:2003:  N: No logrado, si está entre 0% y 15%  P: Parcialmente logrado, si está entre 15% y 50%  L: Ampliamente logrado, si está entre 50% y 85%  F: Completamente logrado, si está entre 85% y 100% Se debe señalar que los valores indicados para separar los niveles de cumplimiento son valores fijos y que tienen un uso referencial puesto a que el que dispone finalmente el nivel de cumplimiento de un proceso es el evaluador y no su porcentaje calculado. Para obtener el perfil de capacidades de los procesos de la empresa Lim.Alfa se realizó una revisión del grado de cumplimiento de las tareas de cada proceso en la empresa. Debido a que no siempre existe documentación formal sobre la realización de estas tareas, además de la revisión de la documentación existente se realizaron entrevistas al personal involucrado en el desarrollo de cada proceso. Después de calcular el grado de cumplimiento de cada tarea de la ISO/IEC 29110 en la empresa se realizó un conteo de las tarea de cada nivel de cumplimiento muestra en la Tabla 4.1 y el factor asociado a estos. Utilizando estos valores y dividiéndolo entre el máximo que se puede obtener si es que todas tareas se encontraran en el grado de cumplimiento máximo, es que se calcula el porcentaje de cumplimiento del proceso. Este esquema de cálculo fue establecido por el investigador principal en los formatos de evaluación. NA N P L F 0 0 0 0.8 1 Table 4.1 Valores de Niveles de Cumplimiento. [Elaboración Propia] Se debe considerar que para la norma ISO/IEC 29110 existen dos niveles de cumplimiento, el nivel 0 y el nivel 1. El nivel 1 es obtenido si es que el grado de cumplimiento del propósito del proceso de la norma ISO/IEC 29110 se encuentra en el máximo grado, que viene a ser el grado F. 34 Los resultados obtenidos son representados en la Tabla 4.2. Procesos PM SI RM PSM PPM Porcentaje de cumplimiento 72,1% 48,8% 17,1% 0,0% 20,0% Grado de cumplimiento L P P N P Nivel 0 0 0 0 0 Table 4.2 Grados de cumplimientos ISO/IEC 29110 [Elaboración propia] En la Figura 4.2 se representa gráficamente la situación de las capacidades de procesos iniciales encontradas en la empresa Lim.Alfa: Figure 4.2 Perfil de Capacidad de Procesos Final [Elaboración Propia] El resultado de la evaluación diagnóstica desarrollada indica que de todos los procesos evaluados de la empresa Lim.Alfa, ninguno cuenta con el nivel de capacidad necesario para ser considerado un proceso completo. Es por esto que se concluye que los 5 procesos evaluados se encuentran en el nivel 0: Proceso Incompleto. 35 4.2.6 Resultados obtenidos El objetivo de esta sección es presentar gráficamente los resultados obtenidos para cada proceso durante la realización de la evaluación diagnóstica en la empresa Lim.Alfa. A. Proceso: Gestión de Proyecto El objetivo de la evaluación para determinar el cumplimiento de este proceso fue relevar información de las actividades desarrolladas con el objetivo de realizar un plan y un control adecuado de los proyectos realizados por la empresa Lim.Alfa. En la evaluación del proceso de Gestión de Proyecto se obtuvo que un 46,2% de las actividades de este proceso cumplían completamente la norma ISO/IEC 29110-5-1-2:2011, el 34,6% de las actividades lograban cumplir largamente con la norma ISO/IEC 29110-5-1-2:2011 y un 19,2% de las actividades lograban cumplir con la norma ISO/IEC 29110-5-1-2:2011 de manera parcial. Como resultado a esto, se obtuvo que en general el proceso de Gestión de Proyecto de la organización poseía un grado de cumplimiento de 72,1% con la norma ISO/IEC 29110-5-1-2:2011. Debido a que el grado de cumplimiento del proceso con la norma ISO/IEC 29110-5-1-2:2011 es menor al 85%, se resuelve que el proceso de Gestión de Proyecto se encuentra en el nivel 0: Proceso Incompleto. de las actividades del proceso de Gestión de Proyecto en los niveles de cumplimiento de la ISO/IEC 15504- 2:2003 tomando como modelo de referencia la ISO/IEC 29110-5-1-2:2011: 36 Figure 4.3 Distribución de cumplimiento del Proceso Gestión de Proyecto [Elaboración Propia] De acuerdo a los resultados obtenidos de la evaluación del proceso de Gestión de Proyecto, se desprenden las siguientes fortalezas y debilidades: Fortalezas  Al momento de la elaboración de la propuesta de trabajo, la empresa Lim.Alfa también realiza la planificación del tiempo, costo y artefactos necesarios para el desarrollo del producto software y los adjunta a la propuesta.  Al momento de realizar la definición del alcance del producto software a desarrollar, la empresa Lim.alfa también incluye imágenes de las pantallas con las que contará el software. Debilidades  Para las estimaciones de costo y tiempo la empresa Lim.Alfa se basa únicamente en la experiencia que poseen. La empresa no posee ningún esquema sistemático para realizar sus estimaciones.  La empresa Lim.Alfa no realiza actualizaciones formales a su Plan de Proyecto donde incluyan variaciones en tiempo, costos, entre otros. 37 Debido a esto no se puede calcular ni el costo real, ni la ganancia real de los proyectos que han realizado.  Existe una falta de formalidad al momento de la elaboración de los documentos que se utilizan en este proceso. Además, sólo se realiza la documentación respectiva cuando el proyecto a desarrollar es considerado por ellos como grande. B. Proceso: Implementación de Software El objetivo de la evaluación para determinar el cumplimiento de este proceso fue relevar información de las actividades desarrolladas con el objetivo de realizar el proceso de construcción de Software, ya sea el diseño, desarrollo, pruebas realizados por la empresa Lim.Alfa. En la evaluación del proceso de Implementación de Software se obtuvo que un 26,8% de las actividades de este proceso cumplían completamente la norma ISO/IEC 29110-5-1-2:2011, el 29,4% de las actividades lograban cumplir largamente con la norma ISO/IEC 29110-5-1-2:2011, un 21,9% de las actividades lograban cumplir con la norma ISO/IEC 29110-5-1-2:2011 de manera parcial y el 21,9% restante no lograban cumplir con la norma ISO/IEC 29110-5-1-2:2011. Como resultado a esto, se obtuvo que en general el proceso de Implementación de Software de la organización poseía un grado de cumplimiento de 48,8% con la norma ISO/IEC 29110-5-1-2:2011. Debido a que el grado de cumplimiento del proceso con la norma ISO/IEC 29110-5-1-2:2011 es menor al 85%, se resuelve que el proceso de Implementación de Software se encuentra en el nivel 0: Proceso Incompleto. La Figura 4.4 representa la distribución de las actividades del proceso de Implementación de Software en los niveles de cumplimiento de la ISO/IEC 15504-2:2003 tomando como modelo de referencia la ISO/IEC 29110-5-1- 2:2011: 38 Figure 4.4 Distribución de cumplimiento del Proceso Implementación de Software [Elaboración Propia] De acuerdo a los resultados obtenidos de la evaluación del proceso de Desarrollo de Software, se desprenden las siguientes fortalezas y debilidades: Fortalezas  Personal técnico capacitado para realizar los productos software de manera adecuada.  Se realiza la asignación de tareas al equipo de trabajo de acuerdo a sus roles y basados en el Plan de Proyecto. Debilidades  Falta de realización de una verificación formal del catálogo de requisitos.  Se debe realizar la trazabilidad de los componentes desarrollados con el diseño del software.  Se deben realizar verificaciones a la documentación del diseño del software para probar que esta sea correcta y consistente con la especificación de requisitos. 39 C. Proceso de Gestión de Recursos El objetivo de la evaluación para determinar el cumplimiento de este proceso fue relevar información de las actividades desarrolladas con el objetivo de realizar el proceso de obtención de recursos para un proyecto, ya sean estos recursos como infraestructura o como personal competente para las funciones necesitadas en un determinado proyecto. En la evaluación del proceso de Gestión de Recursos se obtuvo que un 5,3% de las actividades de este proceso cumplían completamente la norma ISO/IEC 29110-5-1-3, el 15,8% de las actividades lograban cumplir largamente con la norma ISO/IEC 29110-5-1-3, un 42,1% de las actividades lograban cumplir con la norma ISO/IEC 29110-5-1-3 de manera parcial y el 36,8% restante no lograban cumplir con la norma ISO/IEC 29110-5-1-3. Como resultado a esto, se obtuvo que en general el proceso de Gestión de Recursos de la organización poseía un grado de cumplimiento de 17,1% con la norma ISO/IEC 29110-5-1-3. Debido a que el grado de cumplimiento del proceso con la norma ISO/IEC 29110-5-1-3 es menor al 85%, se resuelve que el proceso de Gestión de Recursos se encuentra en el nivel 0: Proceso Incompleto. La Figura 4.5 representa la distribución de las actividades del proceso de Gestión de Recursos en los niveles de cumplimiento de la ISO/IEC 15504- 2:2003 tomando como modelo de referencia la ISO/IEC 29110-5-1-3: 40 Figure 4.5 Distribución de cumplimiento del Proceso Gestión de Recursos [Elaboración Propia] De acuerdo a los resultados obtenidos de la evaluación del proceso de Gestión de Recursos, se desprenden las siguientes fortalezas y debilidades: Fortalezas  Se realiza la identificación de las necesidades de recursos para la organización de manera adecuada.  Se ha iniciado un proceso de revisión de los proveedores de la empresa. Debilidades  Se deben identificar las necesidades de recursos de una manera formal, para esto se deben establecer políticas y mecanismos.  Se debe mantener registros que evidencien la ejecución de las actividades de mantenimiento de los recursos programadas.  Se debe realizar un registro de una evaluación periódica del desempeño de los recursos humanos. 41 D. Gestión de Procesos El objetivo de la evaluación para determinar el cumplimiento de este proceso fue relevar información de las actividades desarrolladas con el objetivo de realizar el proceso de creación y mejora de procesos a lo largo de la organización. En la evaluación del proceso de Gestión de Procesos se obtuvo que un 3,4% de las actividades de este proceso cumplían de manera parcial con la norma ISO/IEC 29110-5-1-3 y el 96,6% restante no lograban cumplir con la norma ISO/IEC 29110-5-1-3. Como resultado a esto, se obtuvo que en general el proceso de Gestión de Procesos de la organización poseía un grado de cumplimiento de 0,0% con la norma ISO/IEC 29110-5-1-3. Debido a que el grado de cumplimiento del proceso con la norma ISO/IEC 29110-5-1-3 es menor al 85%, se resuelve que el proceso de Gestión de Procesos se encuentra en el nivel 0: Proceso Incompleto. La Figura 4.6 representa la distribución de las actividades del proceso de Gestión de Procesos en los niveles de cumplimiento de la ISO/IEC 15504- 2:2003 tomando como modelo de referencia la ISO/IEC 29110-5-1-3: 42 Figure 4.6 Distribución de cumplimiento del Proceso Gestión de Procesos [Elaboración Propia] De acuerdo a los resultados obtenidos de la evaluación del proceso de Gestión de Procesos, se desprenden las siguientes fortalezas y debilidades: Debilidades  Los procesos realizados dentro de la organización no se encuentran documentados.  Se debe realizar la identificación de buenas prácticas o experiencias para la mejora de los procesos. E. Gestión de Portafolio de Proyectos El objetivo de la evaluación para determinar el cumplimiento de este proceso fue relevar información de las actividades desarrolladas con el objetivo de realizar el proceso de gestión de clientes, generación de nuevos proyectos. En la evaluación del proceso de Gestión de Portafolio de Proyectos se obtuvo que un 26,7% de las actividades lograban cumplir largamente con la norma ISO/IEC 29110-5-1-3, un 40,0% de las actividades lograban cumplir con la norma ISO/IEC 29110-5-1-3 de manera parcial y el 33,3% restante no 43 lograban cumplir con la norma ISO/IEC 29110-5-1-3. Como resultado a esto, se obtuvo que en general el proceso de Gestión de Portafolio de Proyectos de la organización poseía un grado de cumplimiento de 20,0% con la norma ISO/IEC 29110-5-1-3. Debido a que el grado de cumplimiento del proceso con la norma ISO/IEC 29110-5-1-3 es menor al 85%, se resuelve que el proceso de Gestión de Portafolio de Proyectos se encuentra en el nivel 0: Proceso Incompleto. La Figura 4.7 representa la distribución de las actividades del proceso de Gestión de Portafolio de Proyectos en los niveles de cumplimiento de la ISO/IEC 15504-2:2003 tomando como modelo de referencia la ISO/IEC 29110-5-1-3: Figure 4.7 Distribución de cumplimiento del Proceso Gestión de Portafolio de Proyectos [Elaboración Propia] De acuerdo a los resultados obtenidos de la evaluación del proceso de Gestión de Portafolio de Proyectos, se desprenden las siguientes fortalezas y debilidades: 44 Fortalezas  Se realiza la confirmación que los recursos aprobados para los proyectos corresponden con los requisitos de los mismos.  Se definen los responsables de los proyectos y se genera documentación técnica sobre los proyectos. Debilidades  Se deben generar y actualizar las políticas del portafolio de proyectos que incluyen políticas de gestión y la relación con el cliente.  Se debe generar un cronograma del portafolio de proyecto y ejecutar las actividades de ese cronograma. Además se deben considerar indicadores para controlar el cumplimiento del cronograma planteado.  Se debe realizar una recolección de comentarios o quejas de los clientes de los proyectos aprobados. Tomando como base la información de los resultados de la evaluación inicial de los procesos de la empresa Lim.Alfa se realizó el Reporte de Evaluación de Procesos. Ver Anexo 4.2 DOC_Reporte de Evaluación de Procesos Inicial 4.3 Plan de mejora de procesos 4.3.1 Identificación de procesos para el ciclo de mejora Los resultados obtenidos del proceso de evaluación realizado para obtener el diagnóstico de la situación inicial de los procesos de la empresa Lim.Alfa demostraron que esta cuenta con un bajo grado de adhesión a la norma ISO/IEC 29110. Luego, estos resultados fueron utilizados para realizar una priorización de los procesos de la empresa y así poder obtener qué procesos serían diseñados y/o rediseñados en la Mejora de Procesos. Para la realización de la identificación de los procesos a ser mejorados en el ciclo de mejora se utilizó una metodología propia del proyecto ProCal-ProSer que tomó como base la metodología de priorización utilizada dentro del proyecto COMPETISOFT. 45 La metodología propia del proyecto ProCal-ProSer utilizada tiene como entradas los objetivos de negocio, los problemas de negocio de la empresa y los procesos a priorizar, y devuelve el grado de impacto positivo en los objetivos de negocio para cada proceso ingresados para su priorización. Esta metodología utilizada realiza la priorización de los procesos mediante la obtención de un coeficiente de priorización que nos permite conocer el grado de impacto que posee la mejora de un proceso en específico sobre los de objetivos de negocio de la empresa. Esto se obtiene realizando los siguientes pasos: 1. Priorización de los Objetivos de Negocio 2. Priorización de los Problemas de Negocio 3. Grado de impacto de los Problemas de Negocio a los objetivos de Negocio. 4. Grado de impacto de una mejora a los procesos a mejorar sobre los Problemas de Negocio. Para realizar el cálculo del grado de impacto tanto del paso 3 como del paso 4 se utiliza la escala de impacto definida en la Tabla 4.3: Bajo Medio Alto 1 2 4 Table 4.3 Escala de Impacto. [Elaboración Propia] 4.3.1.1 Priorización de procesos: Priorización de Objetivos de Negocio Se realizaron entrevistas con la Gerencia de la empresa para obtener los objetivos del negocio a alcanzar. Estos objetivos no se encontraban documentados por lo que se tuvo que apoyar a la gerencia con una investigación para determinar los objetivos del negocio. Después de obtener los objetivos de negocio de la empresa, la gerencia realizó una priorización de los mismos indicando pesos a los objetivos entre el 1 y el 10. Donde a mayor peso el cumplimiento del objetivo de negocio es más importante para la gerencia. Como resultado se obtuvo la Tabla 4.4: 46 Id ObjNeg Descripción larga Peso Porcentaje Priorización ObjN 01 Incrementar en un 25% los ingresos de la empresa. 10 29.41% ObjN 02 Mejorar e innovar en el 50% de los procesos utilizados en el CORE del negocio. 7 20.59% ObjN 03 Disminuir en 10% el número de incidentes reportados por los clientes. 8 23.53% ObjN 04 Disminuir en 10% el tiempo de respuesta de solicitudes de atención. 9 26.47% Table 4.4 Priorización de Objetivos de Negocio. [Elaboración Propia] 4.3.1.2 Priorización de procesos: Priorización de Problemas Se realizaron entrevistas con la Gerencia de la empresa para obtener cuales son los problemas que afectan el cumplimiento de los objetivos de negocio. Después de obtener los problemas se le solicitó a la gerencia que priorizará estos problemas de acuerdo al impacto que tienen en el logro de la visión de la empresa. Para esto, la gerencia indicó pesos a los problemas entre el 1 y el 10. Donde un mayor peso indica un mayor impacto del problema en el logro de la visión de la empresa. Como resultado se obtuvo la Tabla 4.5: Id Problema Descripción larga Impacto Porcentaje Priorización Prob 01 Falta de compromiso de los miembros de los equipos con los proyectos desarrollados. 10 22.22% Prob 02 Los tiempos y costos reales de los proyectos no pueden ser calculados. 6 13.33% Prob 03 Formalmente no existe un plan estratégico. 8 17.78% Prob 04 Falta de estandarización en los documentos generados. 5 11.11% Prob 05 La calidad de los entregables generados dentro del proyecto no es muy alta. 9 20.00% Prob 06 Falta de supervisión y control de las tareas de los proyectos. 7 15.56% Table 4.5 Priorización de Problemas. [Elaboración Propia] 47 4.3.1.3 Priorización de procesos: Grado de impacto de los Problemas de Negocio a los Objetivos de Negocio Teniendo identificados y priorizados los objetivos de negocio y los problemas de negocio, en conjunto con la gerencia de Lim.Alfa se realizó la evaluación del impacto de los problemas encontrados a los objetivos de negocio de la empresa. Utilizando los grados de la escala de impacto de la Tabla 4.3, los problemas de negocio y los objetivos de negocio ya priorizados se obtuvo la Tabla 4.6: Prob 01 Prob 02 Prob 03 Prob 04 Prob 05 Prob 06 P ro b le m a s d e N e g o c io N o s e r e la c io n a n l o s r e q u is it o s q u e s o n d e p e n d ie n te s e n tr e s í. T a m p o c o s e r e la c io n a n l a s s o lic it u d e s d e c a m b io a q u e re q u is it o s y a rt e fa c to s e s p e c íf ic o s a fe c ta rá . N o e x is te m a tr iz d e t ra z a b ili d a d , o s i e x is te n o s e u ti liz a . L o s c a m b io s s e a n e x a n e n f o rm a d e a d e n d a s , lo q u e g e n e ra q u e l o s d e s a rr o lla d o re s t e n g a n q u e l e e rs e t o d o e l d o c u m e n to d e e x tr e m o a e x tr e m o . F a lt a c o n s o lid a r lo s n u e v o s d o c u m e n to s c o n l o s c a m b io s . F a lt a d e c o m p ro m is o d e l o s m ie m b ro s d e l o s e q u ip o s c o n lo s p ro y e c to s d e s a rr o lla d o s . L o s t ie m p o s r e a le s d e e n tr e g a d e l o s p ro y e c to s d if ie re n d e lo s t ie m p o s e s ti m a d o s c o n s id e ra b le m e n te . F o rm a lm e n te n o e x is te u n p la n e s tr a té g ic o . F a lt a d e s u p e rv is ió n y c o n tr o l d e l a s t a re a s d e l o s p ro y e c to s . Objetivos de Negocio % PESO 22.22% 13.33% 17.78% 11.11% 20.00% 15.56% ObjN 01 Consolidar los productos que tenemos en el mercado, además de una mejora continua de los mismos. 29.41% Alto Alto Alto Bajo Alto Alto ObjN 02 Incrementar el número de clientes. 20.59% Alto Medio Alto Medio Alto Alto ObjN 03 Desarrollar nuevos productos que brinden nuevas soluciones y también que atiendan a nuevos mercados haciendo uso de tecnología de punta. 23.53% Alto Bajo Alto Alto Alto Alto ObjN 04 Crear y ofrecer nuevos servicios que permitan a la empresa atender nuevos negocios. 26.47% Alto Bajo Alto Alto Alto Alto Impacto 0.89 0.28 0.71 0.30 0.80 0.62 Table 4.6 Objetivos de Negocio vs Problemas de Negocio. [Elaboración Propia] 48 El cálculo del impacto de cada uno de los problemas identificados en la organización se realizó de la siguiente forma: Se realiza una sumatoria de las multiplicaciones entre el valor de la escala de impacto escogida y mostrada en la Tabla 4.3 y el porcentaje obtenido de la priorización del objetivo de negocio correspondiente. Finalmente esta sumatoria de multiplica por el porcentaje obtenido de la priorización del problema del cual estamos calculando su impacto. Por ejemplo para el problema 1 su impacto se calcularía de la siguiente forma: Impacto Problema 2 = 13.33% * (4*29.41% + 2*20.59% + 1*23.59% + 1*26.47%) = 0.89 De la misma forma se calcularon los impactos para los otros 4 problemas encontrados en la reunión con la gerencia y se obtuvo la Figura 4.8: Figure 4.8 Diagrama de Evaluación de Impacto. [Elaboración Propia] 49 4.3.1.4 Priorización de procesos: Grado de impacto de una mejora a los procesos a mejorar sobre los Problemas de Negocio Habiendo obtenido el grado de impacto de los problemas de negocio a los objetivos de negocio, se realiza el cálculo del grado de impacto de una mejora de los procesos de la ISO/IEC 29110 a estos problemas. Para esto se considera que los 5 procesos de la ISO/IEC 29110 poseen el mismo peso debido a que no existe ningún criterio de priorización entre estos. P ro c e s o s SI PM PSM RM PPM Im p le m e n ta c ió n d e S o ft w a re G e s ti ó n d e P ro y e c to G e s ti ó n d e P ro c e s o s G e s ti ó n d e R e c u rs o s G e s ti ó n d e P o rt a fo lio d e P ro y e c to s Problemas de Negocio Impacto /%PESO 20.00% 20.00% 20.00% 20.00% 20.00% Prob 01 Falta de compromiso de los miembros de los equipos con los proyectos desarrollados. 0.89 Bajo Alto Medio Alto Medio Prob 02 Los tiempos y costos reales de los proyectos no pueden ser calculados. 0.28 Alto Alto Medio Alto Alto Prob 03 Formalmente no existe un plan estratégico. 0.71 Bajo Bajo Medio Bajo Alto Prob 04 Falta de estandarización en los documentos generados. 0.30 Alto Alto Alto Bajo Medio Prob 05 La calidad de los entregables generados dentro del proyecto no es muy alta. 0.80 Alto Alto Medio Bajo Bajo Prob 06 Falta de supervisión y control de las tareas de los proyectos. 0.62 Alto Alto Medio Bajo Alto Impacto 1.92 2.45 1.56 1.42 1.92 Table 4.7 Priorización de Procesos. [Elaboración Propia] Utilizando las condiciones anteriormente descritas es que se realiza el cálculo del grado de impacto. De esta forma se obtiene la Tabla 4.7, donde se puede observar la priorización de los procesos con respecto a los objetivos de negocio. El cálculo del impacto de cada uno de los procesos de la ISO/IEC 29110 en los problemas que posee la organización se realizó de la siguiente forma: 50 Se realiza una sumatoria de las multiplicaciones entre el valor de la escala de impacto escogida para cada problema y mostrada en la Tabla 4.3 y el grado de impacto del problema sobre los objetivos de negocio. Finalmente esta sumatoria de multiplica por el porcentaje de priorización de cada proceso de la ISO/IEC 29110. Por ejemplo para el proceso Implementación de Software (SI) su impacto se calcularía de la siguiente forma: Impacto SI = (1*0.89 + 4*0.28 + 1*0.71 + 4*0.30 + 4*0.80 + 4*0.62) * 20.00% = 1.92 De la misma forma se calcularon los impactos para los otros 4 procesos de la ISO/IEC 29110. En la Figura 4.9 se muestra una comparación de los impactos de todos los procesos de la ISO/IEC 29110 en los problemas del negocio: Figure 4.9 Diagrama de Impactos de Procesos. [Elaboración Propia] Estos grados de impacto obtenidos son utilizados como referencia para la priorización de los procesos de la ISO/IEC 29110. Es con esto que los procesos seleccionados para su priorización son los siguientes:  Gestión de Proyecto (PM)  Implementación de Software (SI) 51 4.3.2 Propuesta de Plan de Mejora Se presentan los estados iniciales de los procesos que fueron seleccionados en el proceso de priorización y los objetivos que se buscan lograr con el desarrollo de las mejoras a estos procesos. Además, a solicitud de la empresa Lim.Alfa, se realiza la propuesta de mejora al proceso de Gestión de Portafolio de Proyectos en puntos que sean relevantes a las mejoras de los procesos de Gestión de Proyecto y Implementación se Software. 4.3.2.1 Gestión de Proyecto Mediante las entrevistas realizadas con el Gerente de la empresa y Gestor de Proyecto, además de la revisión de los documentos que la empresa desarrolló en sus proyectos, se consolidó en la tabla 4.9 la situación inicial de las actividades del proceso de Gestión de Proyecto en la empresa. Tomando como guía la situación inicial de las actividades del proceso de Gestión de Proyecto se realizó el diagrama de flujo del proceso que se muestra en la Figura 4.10. Durante el desarrollo del proyecto se identificó que el proceso de Gestión de Proyecto de la empresa Lim.Alfa carecía de actividades de planificación y control de manera formal. Entre los principales problemas que se encontraron se obtuvieron los siguientes:  No se realizaba una adecuada planificación de los proyectos ni se registraban los cambios a la planificación que ocurrían durante el desarrollo de los proyectos.  No se desarrollaba un análisis de los riesgos relacionados al desarrollo de los proyectos, ni se les realizaba el debido seguimiento a los mismos.  No se realizaba un seguimiento adecuado de los acuerdos y/o comentarios obtenidos por el Gestor de proyecto en las reuniones realizadas con los clientes.  No se realiza un monitoreo adecuado del avance de los proyectos en comparación a la planificación de los mismos. 52 Objetivos Tomando como referencia las necesidades encontradas en la evaluación diagnóstica se han propuesto los siguientes objetivos que el proceso de Gestión de Proyecto debe lograr con el ciclo de mejora: O1 Las Tareas y Los Recursos necesarios para completar el trabajo son dimensionados y estimados. O2 Se realiza el monitoreo del Plan de Proyecto en relación al Registro de Estado de Avance. O3 Los acuerdos realizados en las reuniones con los clientes son documentados y se les realiza seguimiento. O4 Se identifican los riesgos del proyecto durante su realización. SITUACIÓN INICIAL DE MEJORA: PROCESO GESTIÓN DE PROYECTO Roles involucrados Nombre Abreviatura Gestor de Proyecto GP Cliente CL Equipo de Trabajo ET Table 4.8 Roles Proceso Gestión de Proyecto.[Elaboración propia] Actividades Rol Descripción Productos de entrada Productos de salida GP.1 Planeación GP CL GP.1.1 Revisar el enunciado de trabajo. Enunciado de trabajo Enunciado de trabajo [Revisado] GP CL GP.1.2 Definir con el cliente las instrucciones de entrega para los entregables del enunciado de trabajo. Enunciado de trabajo Documento de Alcance -Instrucciones de entrega. GP GP.1.3 Identificar las tareas específicas a realizar para producir los entregables y sus componentes software. Enunciado de trabajo Diagrama de Gantt -Tareas GP GP.1.4 Establecer la duración estimada para realizar cada tarea. Diagrama de Gantt - Tareas Diagrama de Gantt - Duración estimada 53 Rol Descripción Productos de entrada Productos de salida GP GP.1.5 Identificar los recursos: humanos para poder realizar las actividades del proyecto. Enunciado de trabajo Documento de Alcance - Recursos humanos GP GP.1.6 Asignar roles y responsabilidades para cada Tarea. Documento de Alcance -Recursos GP GP.1.7 Asignar las fechas de inicio y fin estimadas con el fin de crear el Cronograma de las Tareas del Proyecto. Diagrama de Gantt -Tareas -Duración estimada Diagrama de Gantt -Cronograma de las Tareas del Proyecto GP GP.1.8 Calcular y estimar el Esfuerzo y Costo estimado del proyecto Diagrama de Gantt -Cronograma de las Tareas del Proyecto Documento de Alcance -Esfuerzo estimado Contrato - Costo estimado GP GP.1.9 Incluir la descripción del producto, los entregables y el alcance en el documento de Alcance Enunciado de trabajo Documento de Alcance -Descripción del producto. - Alcance. - Entregables. GP CLI GP.1.11 Verificar el Documento de alcance. Documento de Alcance Documento de Alcance [verificado] GP ET GP.1.12 Establecer el repositorio del proyecto Repositorio del proyecto GP.2 Ejecución Productos de entrada Productos de salida GP ET GP.2.1 Analizar y evaluar el impacto en esfuerzo, costo y tiempo de la Solicitud de Cambio. La Solicitud de Cambio es propuesta por el Cliente y se obtiene como producto de las reuniones de revisión con el Cliente. Solicitud de Cambio [iniciada] Solicitud de Cambio [evaluada] GP ET GP.2.2 Conducir reuniones de revisión con el Equipo de Trabajo los cuales permiten identificar problemas. ET GP.2.3 Realizar el Respaldo del Repositorio del Proyecto Respaldo del Repositorio del Proyecto 54 Rol Descripción Productos de entrada Productos de salida GP.3 Evaluación y Control Productos de entrada Productos de salida GP ET GP.3.1 Evaluar el progreso del proyecto con respecto al tiempo estimado. *Se realiza de manera informal. Acciones Correctivas GP.4 Cierre Productos de entrada Productos de salida GP CLI GP.4.1 Formalizar la conclusión del proyecto de acuerdo a los acuerdos realizados en el Documento del Alcance. Documento de Alcance. Correo de Aceptación. ET GP.4.2 Actualizar el Repositorio del Proyecto Repositorio del Proyecto Repositorio del Proyecto [Actualizado] Table 4.9 Proceso Gestión de Proyecto inicial.[Elaboración propia] Diagrama de Actividades del proceso de Gestión de Proyecto – Situación Inicial Figure 4.10 Proceso Gestión de Proyecto Inicial. [Elaboración Propia] 4.3.2.2 Implementación de Software La situación inicial de las actividades del proceso de Implementación de Software de la empresa Lim.Alfa se encuentra detallada en la tabla 4.10. Tomando como guía la situación inicial de las actividades de este proceso, se realizó el diagrama de flujo del proceso que se muestra en la Figura 4.11. Durante el desarrollo del proyecto se identificó que el proceso de Implementación de Software de la empresa Lim.Alfa carecía de las siguientes actividades:  No se realizaban actividades que permitan relacionar los componentes generados a lo largo del proceso de desarrollo de software, lo que dificultaba que se realice un adecuado seguimiento a estos componentes.  No se realizaban las actividades necesarias para la actualización del Documento de Diseño del producto software.  No se realizaban las pruebas al software de una manera adecuada y formal. Objetivos Tomando como referencia las necesidades encontradas en la evaluación diagnóstica se han propuesto los siguientes objetivos que se planea que el proceso de Implementación de Software logre con la realización del ciclo de mejora: O1 La arquitectura y el diseño detallado del software es generada o actualizada e incorporada a la línea base. O2 Las pruebas unitarias son definidas y ejecutadas para verificar la consistencia de los requisitos. O3 La trazabilidad de los requisitos, los componentes de diseño y los Casos de Prueba es realizada. 57 SITUACIÓN INICIAL DE MEJORA: PROCESO IMPLEMENCATIÓN DE SOFTWARE Roles involucrados Nombre Abreviatura Gestor de Proyecto GP Cliente CL Analista Programador AP Equipo de Trabajo ET Líder Técnico LT Table 4.10 Roles Proceso Implementación de Software.[Elaboración propia] Actividades Rol Descripción Productos de entrada Productos de salida IS.1 Análisis de Requisitos LT ET IS.1.1 Asignar Tareas a los miembros del Equipo de Trabajo de acuerdo a cada rol para el Análisis de Requisitos. AP CL IS.1.2 Documentar o actualizar la Especificación de Requisitos. Documento de Alcance - Requisitos AP GP IS.1.3 Verificar y obtener la aprobación de la Especificación de Requisitos. Documento de Alcance - Requisitos Documento de Alcance [Verificado] - Requisitos AP CL IS.1.4 Validar y obtener la aprobación de la Especificación de Requisitos. Documento de Alcance [Verificado] - Requisitos Documento de Alcance [Validado] - Requisitos IS.2 Inicio GP ET IS.2.1 Revisar el Documento de Alcance. Documento de Alcance Documento de Alcance [Revisado] GP ET IS.2.2 Establecer o actualizar el ambiente de implementación. Documento de Alcance[Revisado] IS.3 Construcción de Software Productos de entrada Productos de salida LT ET IS.3.1 Asignar tareas a los miembros del Equipo de Trabajo relacionadas a su rol para la construcción de Software. 58 Rol Descripción Productos de entrada Productos de salida AP IS.3.2 Entender el Diseño del Software Diseño del Software [Verificado, en línea base] AP IS.3.3 Desarrollar Software IS.4 Integración y pruebas de software Productos de entrada Productos de salida LT ET IS.4.1 Asignar tareas a los miembros del Equipo de Trabajo relacionadas a su rol para la integración y prueba del software. AP IS.4.2 Integrar el Software construido. Repositorio del Proyecto Repositorio del Proyecto [Actualizado] AP IS.4.3 Realizar las pruebas de Software Software Software [Probado] AP IS.4.4 Corregir los defectos encontrados hasta que sean corregidos. Software [Probado] Software [Corregido] IS.5 Entrega de Producto Productos de entrada Productos de salida LT ET IS.5.1 Asignar tareas a los miembros del Equipo de Trabajo relacionadas a su rol para la entrega del producto. LT IS.5.2 Comprender la configuración de Software Configuración de Software LT IS.5.3 Actualizar el Manual de Mantenimiento. LT IS.5.4 Realizar la entrega de acuerdo a las instrucciones de entrega. Documento de Alcance - Instrucciones de entrega Configuración de Software Table 4.11 Proceso Implementación de Software inicial.[Elaboración propia] Diagrama de Actividades del proceso de Implementación de Software – Situación Inicial Figure 4.11 Proceso Implementación de Software Inicial. [Elaboración Propia] 4.3.2.3 Gestión de Portafolio de Proyectos Durante el desarrollo del proyecto la empresa Lim.Alfa indicó su interés para que en el ciclo de mejora se realicen propuestas para mejorar el proceso de Gestión de Portafolio de Proyectos. El principal interes de la empresa era realizar un control y un seguimiento más adecuado a sus proyectos. Tomando en consideración el interes de la empresa se planeó la realización de mejoras que se encuentren relacionadas a los procesos de Gestión de Proyecto e Implementación de Software y que ayuden a realizar un control y seguimiento más adecuado a sus proyectos. 4.4 Ejecución de las mejoras 4.4.1 Gestión de Proyecto Utilizando la información obtenida de la empresa Lim.Alfa se identificaron una serie de situaciones que impedían el correcto desarrollo del proceso de Gestión de Proyecto de la empresa. Entre estas situaciones tenemos:  La empresa no generaba ningún documento para realizar la planeación del proyecto. Solo existían partes del Plan de Proyecto dentro del Documento de Alcance pero de manera general.  La empresa no generaba Actas de Reunión de las reuniones que tenía con sus clientes. Solo existían correos donde se indicaban los acuerdos realizados, pero no existía un documento formal que indicará lo discutido en la reunión y la aceptación del cliente.  La empresa no realizaba un monitoreo adecuado sobre la ejecución del Plan de Proyecto con respecto a lo que se planeaba. Esto era consecuencia de que no realizaba un Plan de Proyecto donde se indicara de manera detallada las tareas y los tiempos.  La empresa no identificaba los riesgos del proyecto. Esto era un inconveniente puesto que no podían prever posibles problemas que se generaban durante el proyecto. 61 Cuando se analizó la situación del proceso de Gestión de Proyecto de los proyectos pequeños de la empresa Lim.Alfa se obtuvo que no se realizaba una planificación de las actividades y recursos que iban a ser utilizados durante la ejecución de los proyectos. Como consecuencia a la falta de planificación del proyecto, no se podía verificar que el desarrollo del mismo estaba realizándose con los tiempos y costos adecuados. Por esto, se realizó una Plantilla de Plan de Proyecto simplificada para que sea utilizada en los proyectos pequeños de la empresa. Ver Anexo 4.3 PT_Plan de Proyecto Pequeño A lo largo de las ejecuciones de los proyectos no se realizaba una adecuada identificación ni seguimiento a los riesgos de los proyectos. Esto podía generar un problema puesto que no se poseía un registro claro de los riesgos presentes en la realización de los diferentes proyectos. Es debido a esto que se realizó una plantilla para el registro de los riesgos de los proyectos, en la que los Gestores de Proyecto podrían incluir los riesgos de los proyectos y realizarles el debido seguimiento. Ver Anexo 4.4 PT_Registro de Riesgos Cuando se realizaban las reuniones con los clientes de la empresa, no se realizaba un registro de los temas abordados y de los acuerdos aceptados en las reuniones. Esto dificultaba que se pueda realizar un control de los acuerdos aceptados con los diferentes clientes. Tomando esto como base, se realizó la generación de una plantilla de Acta de Reunión que contenga los campos mínimos necesarios para que se tenga un registro de los acuerdos y los involucrados. Ver Anexo 4.5 PT_Acta de Reunión Debido a que una de las principales situaciones que se querían solucionar era que no se realizaba un monitoreo de la ejecución de los proyectos y que ya se había propuesto una plantilla de Plan de Proyecto para que se planifiquen los proyectos, se planteó la generación de Reportes de Avance. Estos Reportes de Avance permitían comparar la ejecución de los proyectos contra su planificación en los documentos de Plan de Proyecto. 62 Ver Anexo 4.6 PT_Reporte de Avance Para el desarrollo del análisis y diseño del proceso de Gestión de Proyecto en la empresa Lim.Alfa se utilizó como referencia la el proceso de Gestión de Proyecto de la ISO/IEC 29110-5-1-2:2011, con lo que se generó el siguiente proceso: [ISO29110] SITUACIÓN PROPUESTA DE MEJORA: PROCESO GESTIÓN DE PROYECTO Definición general del proceso Proceso P1-GP Gestión de Proyecto Nivel Nivel Básico Propósito Este proceso tiene como propósito establecer y llevar a cabo las Tareas de un Proyecto de implementación de Software, de una manera sistemática. Para esto el propósito del proceso debe garantizar que se cumplan con los objetivos de los proyectos en calidad, tiempo y costos esperados. Descripción El proceso de Gestión de Proyecto se encuentra compuesto de las siguientes 4 fases:  Planificación: En esta fase se busca documentar los detalles de planificación necesarios para poder gestionar el proyecto. Entre estos detalles se tienen: - Tareas necesarias para satisfacer los requisitos del cliente. - Roles y responsabilidades. - Necesidades de entrenamiento y Recursos. - Estimación de esfuerzo, costo y cronograma. - Identificación de riesgos. - El Repositorio del Proyecto.  Ejecución: Esta fase provee las actividades para la implementación del plan documentado en el proyecto.  Evaluación y control: Esta fase se encarga de evaluar el desempeño de la ejecución del plan contra los compromisos documentados.  Cierre: Esta fase se encarga de generar la documentación y productos del proyecto de acuerdo a los requisitos especificados en el contrato del proyecto. 63 Objetivos O1 Se desarrolla el Plan de Proyecto de acuerdo al Documento de Alcance. Dentro de este Plan de Proyecto se estiman y dimensionan las Tareas y los Recursos necesarios para completar el proyecto. O2 Se realiza el monitoreo del avance del proyecto contra el Plan del Proyecto. Las correcciones a los problemas son realizadas y son seguidas hasta su cierre. O3 Las solicitudes de cambio son atendidas y los cambios a los requisitos de Software son evaluados de acuerdo a su impacto técnico, en costo y en el cronograma. O4 Se realizan reuniones de revisión con el Equipo de trabajo y el Cliente. O5 Se identifican los riesgos durante el desarrollo y la realización del proyecto. O6 Los elementos de Configuración de Software son identificados, definidos e incorporados a la línea base. O7 Se realiza el aseguramiento de la Calidad del Software desarrollado para proporcionar garantía que el Software se desarrolló cumpliendo con el Plan de Proyecto y los Requisitos. Table 4.12 Definición del Proceso Gestión de Proyecto.[Elaboración propia] Entradas Nombre Fuente Enunciado de trabajo Cliente Solicitud de cambio Cliente Implementación de Software Table 4.13 Entradas al Proceso Gestión de Proyecto.[Elaboración propia] Salidas Nombre Fuente Plan de Proyecto Implementación de Software Acta de Aceptación Alta Dirección Repositorio del Proyecto Implementación de Software Acta de Reunión Cliente Table 4.14 Salidas al Proceso Gestión de Proyecto.[Elaboración propia] 64 Productos internos Nombre Solicitud de Cambio Acciones Correctivas Acta de reunión Reporte de Avance Respaldo del Repositorio del Proyecto Table 4.15 Productos internos del Proceso Gestión de Proyecto.[Elaboración propia] Roles involucrados Nombre Abreviatura Gestor de Proyecto GP Cliente CL Líder Técnico LT Equipo de Trabajo ET Table 4.16 Roles del Proceso Gestión de Proyecto.[Elaboración propia] Actividades Rol Descripción Productos de entrada Productos de salida GP.1 Planificación GP CL GP.1.1 Revisar el enunciado de trabajo. Enunciado de trabajo Enunciado de trabajo [Revisado] GP CL GP.1.2 Definir con el cliente las instrucciones de entrega para los entregables del enunciado de trabajo. Enunciado de trabajo Documento de Alcance -Instrucciones de entrega. GP GP.1.3 Establecer tareas y su duración estimada para poder realizar el proyecto. Documento de Alcance Plan de Proyecto -Tareas - Duración estimada GP GP.1.4 Identificar los recursos: humanos para poder realizar las actividades del proyecto. Enunciado de trabajo Plan de proyecto - Recursos GP GP.1.5 Establecer el equipo de trabajo Plan de proyecto - Recursos Plan de Proyecto - Equipo de trabajo GP GP.1.6 Asignar el tiempo estimado de duración del Proyecto y de sus tareas. Documento de Alcance - Tiempo Estimado Plan de Proyecto - Tiempo Estimado de tareas GP GP.1.7 Calcular y estimar el Esfuerzo y Costo estimado del proyecto Documento de Alcance -Esfuerzo estimado Contrato - Costo estimado Plan de Proyecto -Esfuerzo estimado Contrato - Costo estimado 65 Rol Descripción Productos de entrada Productos de salida GP GP.1.8 Identificar y documentar los riesgos del proyecto Plan de Proyecto - Riesgos GP GP.1.9 Generar el Plan de proyecto incluyendo los elementos anteriormente definidos Plan de Proyecto - Tareas - Duraciones estimadas - Recursos - Equipo de trabajo - Tiempo estimado de tareas - Esfuerzo y costo estimado - Riesgos - Instrucciones de entrega GP GP.1.10 Incluir la descripción del producto, los entregables y el alcance en el Plan de Proyecto Documento de Alcance Plan de Proyecto -Descripción del producto. - Alcance. - Entregables. GP LT GP.1.11 Verificar y obtener la aprobación del Plan de Proyecto. Plan de Proyecto Plan de Proyecto [verificado] GP CL GP.1.12 Revisar y obtener la aceptación del Plan de Proyecto por parte del cliente. Plan de Proyecto[Verificado] Plan de Proyecto[Aceptado] GP ET GP.1.13 Establecer el repositorio del proyecto Repositorio del proyecto GP.2 Ejecución Productos de entrada Productos de salida GP LT ET GP.2.1 Monitorear la ejecución del Plan de Proyecto y registrar los resultados en el Reporte de Avance. Plan de Proyecto Reporte de Avance GP ET GP.2.2 Analizar y evaluar el impacto en esfuerzo, costo y tiempo de la Solicitud de Cambio. La Solicitud de Cambio es propuesta por el Cliente y se obtiene como producto de las reuniones de revisión con el Cliente. Solicitud de Cambio [iniciada] Solicitud de Cambio [evaluada] Plan de Proyecto [Actualizado] 66 Rol Descripción Productos de entrada Productos de salida GP ET GP.2.3 Conducir reuniones de revisión con el Equipo de Trabajo los cuales permiten identificar problemas. GP CL GP.2.4 Conducir reuniones de revisión con el cliente y registrar los acuerdos. Plan de Proyecto Acta de Reunión ET GP.2.5 Realizar el Respaldo del Repositorio del Proyecto. Respaldo del Repositorio del Proyecto GP GP.2.6 Realizar la recuperación del repositorio del proyecto Respaldo del Repositorio del proyecto Repositorio del proyecto [Recuperado] GP.3 Evaluación y Control Productos de entrada Productos de salida GP ET GP.3.1 Evaluar el progreso del proyecto con respecto al Plan de Proyecto. Plan de Proyecto Reporte de Avance Reporte de Avance [Evaluado] GP ET GP.3.2 Establecer acciones para corregir las desviaciones y darles seguimiento hasta su conclusión. Reporte de Avance [Evaluado] Acciones Correctivas GP LT ET GP.3.3 Identificar cambios al Plan de Proyecto para hacer frente a desviaciones importantes del cumplimiento del plan y dar seguimiento hasta su conclusión. Reporte de Avance [Evaluado] GP.4 Cierre Productos de entrada Productos de salida GP CL GP.4.1 Formalizar la conclusión del proyecto de acuerdo a los acuerdos realizados en el Documento del Alcance. Documento de Alcance. Correo de Aceptación. ET GP.4.2 Actualizar el Repositorio del Proyecto Repositorio del Proyecto Repositorio del Proyecto [Actualizado] Table 4.17 Actividades del Proceso Gestión de Proyecto.[Elaboración propia] 67 4.4.2 Implementación de Software Durante el proceso de obtención de información de la empresa Lim.Alfa se identificaron una serie de situaciones que no permitían el correcto desarrollo del proceso de Implementación de Software en la empresa, entre estas situaciones tenemos:  No se realizaba la actualización del Diseño de Software.  No se poseía un documento que permitiera realizar la relación entre los requisitos, el diseño, los casos de prueba y los Componentes de Software.  No se realizaba el diseño de los casos de prueba antes de la generación de los Componentes de Software. Debido a que los proyectos pequeños que realiza la empresa Lim.Alfa consisten en la generación de nuevas funcionalidades a un producto Software que la empresa ya posee, se planteó que en estos proyectos se analice si es necesaria la modificación del Diseño de Software del producto Software y de ser necesario que se actualice este documento. Durante la recolección de información de la empresa se encontró que en los proyectos pequeños los desarrolladores realizaban las pruebas de los Componentes de Software de manera intuitiva después de haberlos desarrollado. Tomando esto como referencia se propone el uso de una plantilla en la que se encuentren generados los Casos de Prueba de los Componentes de Software, y que estos Casos de Prueba se generen antes de que se dé inicio a la generación de los Componentes de Software. Ver Anexo 4.7 PT_Catálogo de Prueba 68 Se planteó que durante el proceso de desarrollo del producto Software se utilice una Matriz de Trazabilidad, la cual relacione los Requisitos, los Componentes de Diseño, los Casos de Prueba y los Componentes de Software. Para esto se generó una plantilla de matriz de trazabilidad que contaba con los siguientes campos:  ID  Necesidades del Cliente  Requisitos Funcionales  Estado (En Progreso, Probando, Completado)  Componente de Diseño asociado  Módulos asociados  Código de Caso de Prueba  Comentarios Ver Anexo 4.8 PT_Matriz de Trazabilidad Al reunir los documentos de proyectos pasados para su análisis se encontró que en estos documentos no existía ninguna prueba de su aprobación, por lo que se planteó que después de realizada la verificación y validación de los documentos, se sellen y se firmen como muestra de la aprobación del documento para ingresar a la Configuración de Software. Para el desarrollo del análisis y diseño del proceso de Implementación de Software en la empresa Lim.Alfa se utilizó como referencia la el proceso de Implementación de Software de la ISO/IEC 29110-5-1-2:2011, con lo que se generó el siguiente proceso: [ISO29110] SITUACIÓN PROPUESTA DE MEJORA: PROCESO IMPLEMENCATIÓN DE SOFTWARE Definición general del proceso Proceso P2-IS Implementación de Software Nivel Nivel Básico 69 Propósito Este proceso tiene como propósito la realización de las actividades de análisis, diseño, construcción, integración y pruebas para los productos de software en base a los requisitos especificados. Descripción El proceso de Implementación de Software está compuesto de 6 fases:  Análisis de Requisitos: Esta fase busca generar los requisitos de software con sus respectivas interfaces de manera correcta.  Inicio: Esta fase busca asegurar que el Plan de Proyecto es llevado a cabo por el equipo de trabajo.  Arquitectura y Diseño detallado del Software: Esta fase se encarga de transformar los requisitos de software en el diseño del software.  Construcción del Software: Esta fase se encarga de desarrollar el código y los datos del Software a partir del diseño y los requisitos de software.  Integración y pruebas de Software: Esta fase se encarga de asegurarse que los Componentes de Software integrados satisfacen los requisitos del Software.  Entrega de Producto: Esta fase se encarga de brindar el producto software desarrollado al cliente. Objetivos O1 Las tareas son realizadas tomando como base el Plan de Proyecto. O2 Los requisitos del Software son definidos, analizados y aprobados por el cliente. O3 La arquitectura y el diseño detallado son desarrollados e incorporados a la línea base. O4 Se producen los Componentes de Software y se definen y ejecutan las pruebas unitarias. O5 El software es producido ejecutando la integración de los Componentes de Software utilizando los casos de prueba para su verificación. O6 Se garantiza la generación de la Configuración de Software según los requisitos acordados con el cliente. O7 Las tareas de verificación y validación de todos los productos de trabajo son realizadas y los defectos son encontrados y corregidos. Table 4.18 Definición del Proceso Implementacón de Software.[Elaboración propia] 70 Entradas Nombre Fuente Plan de Proyecto Gestión del Proyecto Repositorio del Proyecto Gestión del Proyecto Table 4.19 Entradas al Proceso Implementación de Software.[Elaboración propia] Salidas Nombre Fuente Configuración de Software Gestión del Proyecto Solicitud de Cambio Gestión del Proyecto Table 4.20 Salidas al Proceso Implementación de Software.[Elaboración propia] Roles involucrados Nombre Abreviatura Gestor de Proyecto GP Cliente CL Analista Programador AP Equipo de Trabajo ET Líder Técnico LT Table 4.21 Roles del Proceso Implementación de Software.[Elaboración propia] Actividades Rol Descripción Productos de entrada Productos de salida IS.1 Análisis de Requisitos LT ET IS.1.1 Asignar Tareas a los miembros del Equipo de Trabajo de acuerdo a cada rol para el Análisis de Requisitos. Plan de proyecto -Tareas AP CL IS.1.2 Documentar o actualizar la Especificación de Requisitos. Documento de Alcance - Requisitos AP GP IS.1.3 Verificar y obtener la aprobación de la Especificación de Requisitos. Documento de Alcance - Requisitos Documento de Alcance [Verificado] - Requisitos AP CL IS.1.4 Validar y obtener la aprobación de la Especificación de Requisitos. Documento de Alcance [Verificado] - Requisitos Documento de Alcance [Validado] - Requisitos 71 Rol Descripción Productos de entrada Productos de salida IS.2 Inicio de Implementación GP ET IS.2.1 Revisar el Plan de Proyecto. Plan de Proyecto Plan de Proyecto [Revisado] GP ET IS.2.2 Establecer o actualizar el ambiente de implementación. Documento de Alcance[Revisado] IS.3 Arquitectura y Diseño detallado del Software Productos de entrada Productos de salida LT ET IS.3.1 Asignar Tareas a los miembros del Equipo de Trabajo de acuerdo a cada rol para la realización del diseño del software. Plan de proyecto -Tareas AP IS.3.2 Entender la Especificación de Requisitos Documento de Alcance - Requisitos LT IS.3.3 Actualizar el documento de diseño del Software. Diseño de Software Diseño de Software [Actualizado] GP LT IS.3.4 Verificar y obtener la aprobación del diseño de Software. Diseño de Software [Actualizado] Diseño de Software [Verificado] AP IS.3.5 Establecer los casos de prueba en base a los Requerimientos. Documento de Alcance - Requisitos Diseño de Software [Verificado] Casos de prueba LT AP IS.3.6 Verificar y obtener aprobación de los casos de prueba y los procedimientos de prueba. Casos de prueba Casos de prueba [Verificado] LT IS.3.7 Actualizar el Registro de Trazabilidad incorporando los casos de prueba. Casos de prueba [Verificado] Registro de Trazabilidad [Actualizado] Registro de Trazabilidad [Actualizado] LT IS.3.8 Incorporar el Diseño de Software y el Registro de Trazabilidad a la configuración de Software. Diseño de Software [Verificado] Registro de Trazabilidad [Actualizado] Configuración de Software - Diseño de Software [Verificad o] - Registro de trazabilida d [Verificad o] 72 Rol Descripción Productos de entrada Productos de salida IS.4 Construcción de Software Productos de entrada Productos de salida LT ET IS.4.1 Asignar tareas a los miembros del Equipo de Trabajo relacionadas a su rol para la construcción de Software. Plan de proyecto -Tareas AP IS.4.2 Entender el Diseño del Software Diseño del Software [Verificado, en línea base] AP IS.4.3 Desarrollar Software Diseño del Software [Verificado, en línea base] Registro de trazabilidad [Verificado] Componente de Software AP IS.4.4 Aplicar los Casos de Prueba para verificar los Componentes de Software. Componente de Software Componentes de Software [Probado] AP IS.4.5 Corregir los defectos encontrados hasta lograr las pruebas unitarias exitosas. Componentes de Software [Probado] Componentes de Software [Corregido] LT IS.4.6 Actualizar el Registro de Trazabilidad incorporando Componente de Software. Componentes de Software [Corregido] Registro de Trazabilidad [Verificado] Registro de Trazabilidad [Actualizado] LT IS.4.7 Incorporar los Componentes de Software y el Registro de Trazabilidad a la linea base. Configuración de Software [Corregido] Registro de Trazabilidad [Actualizado Configuración de Software [En linea base] Registro de Trazabilidad [En linea base] IS.5 Integración y pruebas de software Productos de entrada Productos de salida LT ET IS.5.1 Asignar tareas a los miembros del Equipo de Trabajo relacionadas a su rol para la integración y prueba del software. Plan de proyecto -Tareas AP IS.5.2 Integrar el Software construido. Repositorio del Proyecto Repositorio del Proyecto [Actualizado] AP IS.5.3 Realizar las pruebas de Software Software Software [Probado] 73 Rol Descripción Productos de entrada Productos de salida AP IS.5.4 Corregir los defectos encontrados hasta que sean corregidos. Software [Probado] Software [Corregido] IS.6 Entrega de Producto Productos de entrada Productos de salida LT ET IS.6.1 Asignar tareas a los miembros del Equipo de Trabajo relacionadas a su rol para la entrega del producto. Plan de proyecto -Tareas LT IS.6.2 Comprender la configuración de Software Configuración de Software LT IS.6.3 Actualizar el Manual de Mantenimiento. LT IS.6.4 Realizar la entrega de acuerdo a las instrucciones de entrega. Documento de Alcance - Instrucciones de entrega Configuración de Software Table 4.22 Actividades del Proceso Implementación de Software.[Elaboración propia] 4.4.3 Gestión de Portafolio de Proyecto Durante la ejecución del ciclo de mejora en la empresa Lim.Alfa se desarrollaron las siguientes mejoras que ayudaron a mejorar el control de los proyectos dentro del proceso de Gestión de Portafolio de Proyectos: Se propuso a la empresa realizar la recolección de los Reportes de Avance de los diferentes proyectos que realizan, para que luego de realizar un análisis de estos reportes se realicen acciones correctivas. Las acciones correctivas generadas eran registradas en un Excel en el cual se mantenía un registro de todas las acciones correctivas que se encontraban activas en los diferentes proyectos de la empresa. Ver Anexo 4.9 PT_Registro Acciones Correctivas 4.5 Evaluación de mejoras introducidas Al finalizar el primer ciclo de mejora realizado dentro de la empresa Lim.Alfa dentro del marco del proyecto ProCal-ProSer se realizó una evaluación final con el objetivo de medir el grado de adhesión de los procesos de la empresa Lim.Alfa luego de la ejecución del Plan de Mejora de Procesos propuesto en relación a los perfiles básico 74 e intermedio de la ISO-IEC 29110. Este proceso de evaluación fue similar al utilizado al inicio del proyecto con la diferencia que se este toma en cuenta el impacto de las mejoras introducidas a la empresa. Lo primero que se realizó fue generar un documento que contenga la planificación de la evaluación final de los procesos de la empresa. Ver Anexo 4.10 DOC_Plan Evaluación de Procesos Final La Tabla 4.23 representa los resultados obtenidos del proceso de evaluación de las capacidades de los procesos de la situación de la empresa Lim.Alfa luego de la ejecución del primer ciclo de mejora: Procesos PM SI RM PSM PPM Porcentaje de cumplimiento 82,7% 56,7% 25,0% 5,2% 20,0% Grado de cumplimiento L L P N P Nivel 0 0 0 0 0 Table 4.23 Nivel de Cumplimiento de Procesos Final [Elaboración Propia] Al realizar la evaluación de la situación final de los procesos de la empresa Lim.Alfa se obtuvo que los porcentajes de cumplimiento de los procesos de Gestión de proyectos, Implementación de Software y Gestión de Portafolio de Proyectos lograron incrementarse. Este incremento en los porcentajes de cumplimiento generó que los niveles de cumplimiento de los procesos de Gestión de Proyecto e Implementación de Software se incrementaran, por lo que lograron un grado de cumplimiento de L. En la Figura 4.12 se representa los porcentajes de cumplimiento de cada proceso de la empresa Lim.Alfa tomando como referencia los perfiles básico e intermedio de la NTP ISO-IEC 29110-5-1-2: 75 Figura 4.12 Perfil de Capacidad de Procesos Final. [Elaboración Propia] Para los procesos de Gestión de Recursos y Gestión de Procesos si bien los porcentajes de cumplimiento de estos procesos se incrementaron, sus niveles de cumplimiento con respecto al perfil intermedio de la NTP ISO/IEC 29110-5-1-2 no lo hicieron. Esto es debido a que los incrementos en los porcentajes de cumplimiento de los procesos no fueron lo suficientemente grandes como para que los niveles de cumplimiento se incrementaran. Proceso Nivel de adhesión planificado % Evaluación Inicial (%) Evaluación Final (%) Final vs. Planificado (%) PM 95 72.1 82.7 87 SI 95 48.8 56.7 59.6 Procesos afectados durante la implementación del Plan de Mejora Proceso Nivel de adhesión planificado % Evaluación Inicial (%) Evaluación Final (%) Delta (%) RM - 17.1 25 7.9 PSM - 0 20 20 Table 4.24 Logros del Ciclo de Mejora según Objetivos de Mejora. [Elaboración Propia] 76 En la tabla 4.24 se representa la comparación entre el nivel de adhesión planificado y el porcentaje de adhesión obtenido luego de la ejecución del primer ciclo de mejora de procesos en la empresa Lim.Alfa. Se debe señalar que los procesos que contaban con un nivel de adhesión planificado son los procesos de Gestión de Proyecto e Implementación de Software. En el caso del proceso de Gestión de Recursos no se planificó un porcentaje de adhesión a lograrse con la aplicación del ciclo de mejora debido a que este proceso no fue seleccionado en la priorización de procesos, y solo se le realizaron mejoras puntuales a ciertas actividades que la empresa deseaba mejorar. Para el caso del proceso de Gestión de Procesos, no se le realizó ninguna mejora pero su porcentaje de adhesión a la norma se incrementó debido a que la realización del ciclo de mejora de procesos en la empresa hizo que se generaran algunas de las actividades de este proceso. Finalmente se utilizó esta evaluación final para generar el Reporte Técnico correspondiente. Ver Anexo 4.11 DOC_Reporte Técnico 4.6 Problemas identificados y acciones tomadas Durante la ejecución del ciclo de mejora de procesos en la empresa Lim.Alfa se encontraron una serie de problemas que dificultaron la realización del ciclo de mejora: Problema Acción tomada Inicialmente existió dificultad para la obtención de información privada de la empresa. Se tuvo una reunión entre un miembro del proyecto ProCal-ProSer y la gerencia de la empresa para concientizar a la empresa y que brinde la información solicitada en un plazo razonable. Existió una dificultad para las comunicaciones con los miembros de la gerencia de Lim.Alfa para coordinar la entrega de información. Se realizó la solicitud de varios documentos y se solicitó una reunión con la gerencia de Lim.Alfa en la que se solucionaron todas las dudas generadas. 77 Problema Acción tomada Al solicitar los objetivos de negocio de la empresa, la gerencia de esta se demoró un plazo de dos semanas para entregar este punto. Se realizó una reunión entre un miembro del proyecto ProCal-ProSer y la gerencia de la empresa en la que se acordó brindar ejemplos de objetivos de negocio para que la gerencia de la empresa pueda desarrollar sus objetivos de negocio. Existió la dificultad para programar la priorización de los procesos con la gerencia de la empresa. Esto se debe principalmente a que el proceso de priorización tenía una duración mayor que el resto de reuniones realizadas con la gerencia. Se insistió en que la priorización era un punto importante que se tenía que realizar antes de poder seguir con el desarrollo del proyecto. Se recalcó que de no llevarse a cabo la priorización, el desarrollo del proyecto se iba a extender. La gerencia de la empresa poseía un retraso en aprobar las mejoras propuestas para los procesos seleccionados. Se fueron entregando las propuestas de mejora del segundo proceso seleccionado mientras se iban concluyendo y no después de haber terminado todas las propuestas de mejora de todo el proceso. Table 4.25 Problemas identificados y Acciones tomadas [Elaboración propia] 78 5 Observaciones, Conclusiones y Mejora En este punto se indican observaciones obtenidas durante el desarrollo del ciclo de mejora en la organización, conclusiones de lo realizado en el ciclo de mejora y recomendaciones que la empresa debe tomar en cuenta. 5.1 Observaciones Durante el desarrollo del proyecto en la empresa, se obtuvieron las siguientes observaciones:  La elección de las herramientas utilizadas tuvo que tomar en consideración los lineamientos que se tenían del proyecto ProCal-ProSer y las facilidades que brindó la empresa para el uso de estas.  Durante el desarrollo del proyecto en la empresa, se realizaron reuniones semanales con otros miembros del proyecto ProCal-ProSer para así compartir experiencias de la implementación del ciclo de mejora en diferentes empresas.  Durante el desarrollo del proyecto se tuvieron visitas a la empresa por parte de un investigador del proyecto ProCal-ProSer, para poder llevar un control del avance del proyecto en la empresa y asegurar que la empresa brinde todas las facilidades para el desarrollo del proyecto.  La empresa a la cual se le realizó el ciclo de mejora no contaba con herramientas automatizadas para la gestión de proyectos por lo que los formatos y documentación generada se realizacrón utilizando hojas de cálculo y procesadores de texto. 5.2 Conclusiones Tomando como base las activides desarrolladas durante la implementación del ciclo de mejora en la empresa Lim.Alfa, se han obtenido las siguientes conclusiones:  Se realizó satisfactoriamente un primer ciclo de mejora de procesos en la empresa Lim.Alfa.  Con la realización del diagnóstico de la situación inicial de la empresa se obtuvo que tomando como referencia los procesos de la norma ISO/IEC 29110, perfil básico e intermedio, todos estos procesos se encontraban en el nivel 0: Proceso Incompleto. 79  Tomando como base el diagnóstico de la situación inicial de la empresa, la priorización de los procesos de la empresa y la disponibilidad de la empresa, se realizó la planificación de la mejora de los dos procesos seleccionados.  Se realizó la ejecución del ciclo de mejora de acuerdo al plan que se había establecido y se realizaron mejoras adicionales al proceso de Gestión de Portafolio de Proyecto a pedido de la empresa Lim.Alfa.  Se realizó una evaluación de la situación final de la empresa Lim.Alfa luego de realizarse la ejecución del ciclo de mejora de procesos.  Se elaboró el reporte técnico tomando como referencia la evaluación final desarrollada. 5.3 Recomendaciones  Considerando que ya se ha realizado un ciclo de mejora a los procesos de Gestión de Proyectos y Desarrollo de Software, se recomienda desarrollar un ciclo de mejora al proceso de Gestión de Portafolio de Proyecto ya que este la empresa ha señalado interes en las actividades de este proceso.  Se recomienda que para un próximo ciclo de mejora se busque que la gerencia comprometa mayor parte de su tiempo a la mejora de los procesos de la organización.  Se recomienda asignar a una persona de la organización la tarea de realizar el seguimiento y control de los procesos mejorados y críticos de la empresa. Esto se debe realizar con el apoyo de la gerencia para que la empresa pueda realizar la mejora continua de sus principales procesos. 80 6 Bibliografía [APESOFT2014]APESOFT. (s.f.). Recuperado el 19 de 05 de 2014, de http://www.apesoft.org/ [BIZAGI]BIZAGI. (s.f.). Bizagi Process Modeler User's Guide. Recuperado el 06 de 06 de 2014, de http://help.bizagi.com/processmodeler/en/ [BPMN2011]Object. (2011). Business Process Model and Notation (BPMN) Version 2.0. [CMMI2014]University, C. M. (2010). CMMI for Development, Version 1.3. Hanscom. [DRAE2001]Diccionario de la lengua española (Vigésimo segunda ed.). (2001). Madrid, España. [GRIFFITH2014]University, G. (2014). The SPICE document suite-Concepts and introductory guide. [IEEE2007]Socierty, I. C. (2007). Software Process Improvement: The Competisoft Project. [ISO12207]Comerciales-INDECOPI, C. d. (2006). NTP-ISO/IEC 12207:2006 Tecnología de la información. Procesos del ciclo de vida del software. Lima: Indecopi. [ISO29110]ISO/IEC 29110-5-1-2. (2011). Software engineering - Lifecycle profiles for Very Small Entities(VSEs). Suiza: ISO. [ISO3]ISO/IEC 29110-5-1-3. Software engineering - Lifecycle profiles for Very Small Entities(VSEs). Management and engineering: Generic profile group: Intermediate profile [ISO9000]ISO 9000 Sistemas de gestión de la calidad, fundamentos y vocabulario. (2005). Ginebra: Suiza. [MENDEZ2012]Angel, M. B. (2012). Mejora del proceso software de una pequeña empresa desarrolladora de software: caso competisoft-Perú-Lim.OMEGA, Primer ciclo. Lima. [MPS2005], Alquicira Esquivel, C., Su Ramos, A., Martínez Martínez, A., Ruvalcaba López, M., Rivera López, M. E., y otros. (2005). MoProSoft v1.3: Modelo de Procesos para la Industria de Software. México: Secretaría de Economía. [NTP29110]Arancelarias-INDECOPI, C. d. (2012). NTP-RT-ISO/IEC TR 29110-5- 1-2 2012. Lima: Indecopi. [PCHILE2013]Perú, O. C. (s.f.). ProChile. Recuperado el 15 de 05 de 2014, de www.prochile.gob.cl [PCPS2014]Dávila, A. (s.f.). ProCal-ProSer. (Google Sites) Recuperado el 16 de 04 de 2014, de https://sites.google.com/a/pucp.pe/procal-proser/ [PMI2000]PMI. (2000). A Guide to he Project Management Body of Knowledge. Maryland: Project Management Institute, Inc. [PROD2011]Dirección General de Estudios Económicos, E. y. (2011). MMYPE 2011 Estadísticas de la micro y pequeña empresa. Lima: Ministerio de la producción. [SEI2006]University, C. M. (s.f.). Carnegie Mellon Software Engineering Institute. Recuperado el 20 de 04 de 2014, de http://resources.sei.cmu.edu/asset_files/presentation/2006_017_001_23388.p df [SOFTEX2012]SOFTEX. (2012). Guía General MPS de Software. Brasil. 81 University, [. E. (s.f.). Software Engineering Institute | Carnegie Mellon University. Recuperado el 06 de 06 de 2014, de http://www.sei.cmu.edu/