PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ ESCUELA DE POSTGRADO MAESTRÍA EN INFORMÁTICA MENCIÓN EN INGENIERÍA DE SOFTWARE Implementación de la ISO/IEC 12207:2008 para mejorar los procesos asociados al ciclo de vida de software en una micro empresa peruana cuyo objeto social es el desarrollo de sistemas de información Autor: Supervisor Ing. Lilly del Carmen Horna Merino Mag. Luis Flores García 11 de Octubre del 2014 2 INDICE PRESENTACIÓN DEL PROYECTO ........................................................................................... 3 1.1. INTRODUCCIÓN .................................................................................................................... 3 1.2. DEFINICIÓN DEL PROBLEMA .................................................................................................... 3 1.3. OBJETIVO GENERAL ............................................................................................................. 4 1.4. OBJETIVOS ESPECÍFICOS ...................................................................................................... 5 1.5. RESULTADOS ESPERADOS ..................................................................................................... 5 1.6. JUSTIFICACIÓN ..................................................................................................................... 5 1.7. MÉTODOS Y PROCEDIMIENTOS ............................................................................................... 6 MARCO DE REFERENCIA ....................................................................................................... 8 2.2 CONCEPTOS A SER UTILIZADOS ........................................................................................... 8 2.3 MODELOS DE CALIDAD DE PROCESOS ................................................................................... 9 2.3.1 ISO 9001 ...................................................................................................................... 10 2.3.2 ISO/IEC 12207 ............................................................................................................. 10 2.3.3 CMMI ........................................................................................................................... 11 2.3.4 MOPROSOFT ................................................................................................................. 13 2.3.5 MPS.BR ....................................................................................................................... 13 2.3.6 ISO/IEC 29110 ............................................................................................................. 14 2.4 MÉTODOS DE EVALUACIÓN DE PROCESOS ........................................................................... 15 2.4.1 ISO/IEC 15504 ............................................................................................................. 15 2.4.2 SCAMPI ....................................................................................................................... 17 2.4.3 EVALPROSOFT .............................................................................................................. 18 2.5 MÉTODOS DE MEJORA DE PROCESOS DE SOFTWARE ........................................................... 18 2.5.1 AGILE SPI ..................................................................................................................... 19 2.5.2 IDEAL .......................................................................................................................... 20 2.5.3 PMCOMPETISOFT ...................................................................................................... 22 2.6 COMPETISOFT ........................................................................................................... 23 2.7 COMPETISOFT – PERU ............................................................................................... 24 2.8 PACIS ......................................................................................................................... 24 2.9 RELAIS ........................................................................................................................ 25 EMPRESA DE ESTUDIO ........................................................................................................ 27 DESARROLLO DEL PROYECTO ............................................................................................ 30 4.1 PROCESOS A SER EVALUADOS .......................................................................................... 30 4.1.1 RESULTADOS OBTENIDOS ................................................................................................ 30 4.1.2 TÉCNICA DE OBTENCIÓN DE DATOS .................................................................................... 30 4.1.3 EVALUACIÓN INICIAL ........................................................................................................ 31 4.1.4 SELECCIONANDO LOS PROCESOS PARA LA PROPUESTA DE PLAN DE MEJORA ........................... 37 4.1.5 ESQUEMA PARA LA DEFINICIÓN DE LA MEDIDA DE RENDIMIENTO DE UN PROCESO. ...................... 39 4.1.5.1 PROCESO DE GESTIÓN DE RIESGOS............................................................................... 44 4.1.5.2 PROCESO DE ACEPTACIÓN DE SOFTWARE ...................................................................... 48 4.1.5.3 PROCESO DE GESTIÓN DE ACTIVOS DE REUSO ................................................................ 52 CONCLUSIONES Y RECOMENDACIONES ............................................................................. 57 5.1 CONCLUSIONES .............................................................................................................. 57 5.2 RECOMENDACIONES ....................................................................................................... 58 REFERENCIAS ..................................................................................................................... 84 3 Capítulo 1 Presentación del Proyecto El proyecto de tesis pretende evaluar los procesos priorizados por la micro empresa asociados al ciclo de vida de desarrollo de software y elaborar propuestas de mejora teniendo como marco la ISO/IEC 12207:2008. Para ello en esta primera parte se realiza la presentación e introducción al proyecto, definición del problema, definición de objetivos, resultados esperados, justificación, métodos y procedimientos. 1.1. Introducción Las Normas Internacionales traen beneficios tecnológicos, económicos y sociales 27. Ayudan a armonizar las especificaciones técnicas de los productos y servicios haciendo a la industria más eficiente, permitiendo su ingreso al comercio internacional y a los consumidores a través de productos seguros y eficaces 27. Cabe indicar que el 90% de las 300 empresas desarrolladoras de software en el Perú, son micro y pequeñas7, según la Comisión de Promoción del Perú para la Exportación y el Turismo – PROMPERÚ; por ello, al ser las mypes el tipo de empresa que representa la mayor proporción para desarrollar software, se presenta la necesidad de apoyarlas para que sean cada vez más competitivas y una forma de alcanzarlo es a través del uso de estándares internacionales. Para el presente proyecto de tesis, se pretende evaluar los procesos asociados al ciclo de vida de desarrollo de software en una mype y plantear propuestas de mejora de procesos tomando como marco de referencia la ISO/IEC 12207:2008 para la evaluación y mejora de procesos en microempresas y pequeñas empresas desarrolladoras de software. Por otro lado, las pequeñas empresas desarrolladoras de software en el Perú tienen respaldo del Centro de Innovación Tecnológica de Software (CITE Software), que ha sido creado, según resolución Nº 002-2007- Produce/DVI, con el ánimo de promover el desarrollo y la innovación tecnológica de la industria peruana de software, especialmente mypes y brinda a las empresas de la cadena productiva de software, servicios tecnológicos que ayuden a fortalecer su competitividad y mejorar su productividad 5. 1.2. Definición del problema 4 Uno de los factores importantes que genera una imagen positiva en una empresa desarrolladora de software es un buen producto de software y servicio; y para alcanzarlo es conveniente considerar los estándares de calidad presentados por la ISO/IEC y otros marcos de referencia como MOPROSOFT, COMPETISOFT que elevan la calidad de los procesos involucrados en el desarrollo del producto de software; dichos estándares o marcos de referencia constituyen buenas prácticas para mejorar los procesos involucrados en la realización de los proyectos, incorpora temas de gestión de negocios, procesos, recursos, administración, desarrollo y mantenimiento de software 37; para el presente proyecto se realizó a través de la aplicación de la ISO/IEC 12207 en una empresa en particular. Existen proyectos que se han realizado para la evaluación y mejora de procesos del ciclo vida de software en pequeñas empresas, tal es el caso del proyecto COMPETISOFT, que busca que las empresas desarrolladoras de software de los países iberoamericanos, dentro de los cuales se encuentra Perú, mejoren sus procesos software y en tal sentido tengan las competencias necesarias para colocarse en el mercado internacional a través de la aplicación de los modelos propuestos por el proyecto 39. Por otro lado, la ISO / IEC 29110 considera un conjunto de normas e informes técnicos que se ha desarrollado para las pequeñas empresas (VSE – Very Small Entities) reconociendo a éstas como proveedoras de software de alta calidad. Dicha norma fue adoptada en el Perú a través de NTP- ISO/IEC 29110 19. En este contexto, la tesis busca responder a la pregunta ¿cómo aplicar la ISO/IEC 12207:2008 en una mype?. Por ello se presenta un estudio de caso a través de la aplicación de la ISO/IEC 12207 en una microempresa desarrolladora de software. Se realizará la evaluación de los procesos asociados al ciclo de vida de desarrollo de software, considerando aquellos procesos que afecten en mayor medida los objetivos de negocio; y en base a dichos resultados se realizarán propuestas para la mejora de los procesos teniendo como marco de referencia la ISO/IEC 12207. La metodología aplicada para el análisis, evaluación y propuestas de mejora son tomadas de los documentos del proyecto COMPETISOFT 52. Las propuestas serán llevadas a cabo a través de un piloto, cuya implementación al final se evaluó a fin de verificar si los procesos mejoraron. 1.3. Objetivo General Implementar un conjunto de propuestas de mejora de procesos en una micro empresa en base a las evaluaciones de los procesos priorizados que corresponden al ciclo de vida de desarrollo de software, tomando como referencia la ISO/IEC 12207:2008. 5 1.4. Objetivos Específicos Los objetivos específicos son: O1: Realizar el diagnóstico de los procesos según el ciclo de vida de desarrollo de software. O2: Elaborar propuestas de mejora de procesos según las mejoras prácticas. O3: Implementar el piloto con las propuestas de mejora y realizar las evaluaciones correspondientes. 1.5. Resultados Esperados Los resultados esperados son: O1: Realizar el diagnóstico de los procesos según el ciclo de vida de desarrollo de software. R1: Informe de fortalezas y debilidades, perfil de capacidades de los procesos actuales. O2: Elaborar propuestas de mejora de procesos según las mejoras prácticas. R2: Propuesta de mejora de los procesos de ciclo de vida de desarrollo de software. O3: Implementar el piloto con las propuestas de mejora y realizar las evaluaciones correspondientes. R3: Obtención de las evaluaciones y conclusiones de la aplicación de las propuestas de mejora de ciclo de vida de desarrollo de software, las cuales se detallan a partir de la sección 4.1.5.1. 1.6. Justificación “La industria de software representa una actividad económica de suma importancia para todos los países del mundo. Ofrece múltiples fuentes de negocio y se perfila como la oportunidad más grande de los países en vía de desarrollo. Pero, en los países latinoamericanos la industria de software es incipiente e inmadura” 47. “Al 2013, existen unas 60 millones de pymes en Latinoamérica y el Caribe, de las cuales un gran porcentaje aún no han despertado al mundo tecnológico. Del lado de la demanda es clave mencionar que 6 más del 70% de las pymes que habían incorporado soluciones de software de calidad mejoraron sus costos entre un 5 y 25% y más de un 80% incrementó sus ventas entre el 5 y el 25%” 40. Particularmente considero que si la empresa de software cuenta con procesos optimizados podrá cubrir la demanda que presenta el gran mercado de mypes; para ello se orientará hacia la obtención de la calidad a nivel de productos, servicios o procesos, lo que permitirá generar confianza en el cliente, toda vez que un producto eficiente y entregado a tiempo da como resultado un cliente satisfecho. Actualmente en el Perú está vigente la NTP ISO/IEC 12207:2006; Tecnología de la Información. Procesos del ciclo de vida del software, como marco de referencia del ciclo de vida del software desde la conceptualización de ideas hasta su retirada y consta además de procesos para adquirir, desarrollar, mantener y suministrar productos y servicios software 20. Cubre además el control y la mejora de estos procesos 32. Considerando que la ISO/IEC 12207 es una Norma Técnica Peruana, para el modelo de referencia se ha utilizado la ISO/IEC 12207:2008 33, toda vez que es la norma internacional más actual. El proyecto de tesis considera la mejora de los procesos que afectan en mayor medida los objetivos de negocio de una micro empresa a la cual de ahora en adelante se le denominará X a fin de garantizar la confidencialidad de la misma. Para ello se toma como base a la norma ISO/IEC 12207:2008 Proceso de Ciclo de Vida de Software y la ISO/IEC 15504-5, un Ejemplo del Modelo de Evaluación de Proceso. El proyecto pretende evaluar los procesos priorizados (Capítulo 4) asociados al ciclo de vida de desarrollo de software de una micro empresa y elaborar propuestas de mejora teniendo como marco la ISO/IEC 12207:2008. Estas propuestas serán implementadas y probadas a través de un proyecto piloto. Para ello la organización debe invertir tiempo y recursos a fin de cumplir los objetivos de este proyecto, toda vez que ella se beneficia; por lo que tendrá que asumir el compromiso desde la Gerencia General hasta el equipo técnico del proyecto. 1.7. Métodos y procedimientos El presente proyecto pretende evaluar los procesos asociados al ciclo de vida de desarrollo de software en una microempresa, y para ello se realizarán reuniones de trabajo con la parte gerencial, administrativa y 7 operativa de la empresa. Para desarrollar el proyecto, el cual estuvo programado para 9 meses de trabajo; se realizó el planteamiento el problema, la revisión de conceptos y literatura asociada, se propuso la creación de formatos y documentación para facilitar la mejora de procesos en la empresa. Para lograr los resultados deseados se propuso desarrollar las siguientes actividades: R1: Diagnóstico y evaluación  Evaluación inicial de la empresa a través del análisis preliminar, número de trabajadores, cartera de clientes, entrevistas a los encargados de la empresa y equipo de TI. Inicialmente se planteó evaluar todos los procesos de la ISO/IEC 12207:2008 versus los objetivos y problemas del negocio, con fin de determinar los procesos a mejorar (priorización de procesos).  Para determinar el grado de cumplimiento de la empresa con respecto a los procesos de la ISO/IEC 12207:2008, tomando como marco de evaluación la ISO/IEC 15504-5 32, se elaboraron cuestionarios, plantillas en Excel como técnica para evaluar procesos de la norma, problemas y objetivos de negocio 48. R2: Propuestas de mejora, implementación de piloto y lecciones aprendidas  Se mejoraron los procesos seleccionados de acuerdo a los objetivos de negocio, luego se probaron en el piloto con la participación del personal de la empresa.  Se aplicó el cuestionario de procesos nuevamente, pero esta vez verificando las evidencias para sustentar las respuestas. Así, se obtuvo el nuevo porcentaje de cumplimiento y nivel de capacidad de cada proceso.  Se presentó a la gerencia los resultados y mejora alcanzada en los procesos seleccionados, así como las lecciones aprendidas. 8 Capítulo 2 Marco de Referencia La definición de modelos de calidad y mejora de procesos de software para pequeñas empresas demuestra ser un punto clave y de rápido crecimiento en el contexto iberoamericano 45. Prueba de ello son los proyectos de investigación desarrollados en México con la definición del Modelo de Procesos para la Industria del Software (MOPROSOFT), Brasil con su Modelo de Referencia para la Mejora de Proceso de Software (MPS.BR), el proyecto "Mejora de Procesos para Fomentar la Competitividad de la Pequeña y Mediana Industria del Software de Iberoamérica" (COMPETISOFT) 45 y la ISO / IEC 29110 que se ha desarrollado para las pequeñas empresas. Es por ello, que el marco de referencia presenta la información necesaria para comprender los conceptos y antecedentes utilizados en el proyecto.  La primera sección abarca los modelos de calidad de proceso (ISO 9001:2000, ISO/IEC 12207, CMMI, MOPROSOFT, MPS.BR, ISO/IEC 29110).  La segunda sección cubre los modelos de evaluación de procesos (ISO/IEC 15504, SCAMPI, EVALPROSOFT).  La tercera sección trata los modelos de mejora de procesos (AGILE SPI , IDEAL, PMCOMPETISOFT)  Finalmente, el proyecto COMPETISOFT, COMPETISOFT- PUCP, PACIS, RELAIS. 2.1 Conceptos a ser utilizados Modelo del ciclo de vida: Marco de referencia que contiene los procesos, actividades y tareas involucradas en el desarrollo, operación y mantenimiento de un producto software y que abarca toda la vida del sistema desde la definición de sus requerimientos hasta el final de su uso 20. Calidad: Calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario 16. 9 Proceso: Conjunto de actividades mutuamente relacionadas o que interactúan, las cuales transforman elementos de entradas en resultados 20. A partir de los conceptos mencionados anteriormente se puede entender que: Modelo de Calidad de Proceso: es un conjunto de buenas prácticas que describen las características de un proceso efectivo. Evaluación: La Real Academia de la Lengua Española (RAE) lo define como: estimar, apreciar, calcular el valor de algo 15. ISO / IEC: La Organización Internacional de Normalización o ISO, nacida tras la Segunda Guerra Mundial (23 de febrero de 1947), es el organismo encargado de promover el desarrollo de normas internacionales de fabricación (tanto de productos como de servicios), comercio y comunicación para todas las ramas industriales a excepción de la eléctrica y la electrónica. Su función principal es la de buscar la estandarización de normas de productos y seguridad para las empresas u organizaciones (públicas o privadas) a nivel internacional 1. La Comisión Electrotécnica Internacional (IEC) es la organización líder mundial que prepara y publica estándares internacionales para todas las tecnologías eléctricas, electrónicas y relacionadas 8. Más de 10 000 expertos de la industria, grupos de comercio, gobierno, de prueba y laboratorios de investigación, la academia y los consumidores participan en el trabajo de normalización IEC. La IEC es una de las tres organizaciones mundiales hermanas (IEC, ISO, ITU) que desarrollan Normas Internacionales para el mundo. 8 Por otro lado, la IEC colabora con la ISO (Organización Internacional de Normalización) o la UIT (Unión Internacional de Telecomunicaciones) para asegurar que las normas internacionales se ajusten y complementen entre sí 8. 2.2 Modelos de calidad de procesos Los modelos de calidad de procesos software son aquellos que definen cuáles son las mejores prácticas que una organización debe implementar para el desarrollo de software y las características que deben cumplir las organizaciones, lo cual se traduce en la obtención de 10 un nivel de madurez 36. Estos modelos se presentan de forma genérica, lo que les permite ser adoptados e interpretados según la realidad de las organizaciones 36. Entre los principales modelos se puede mencionar: ISO 9001:2000, ISO/IEC 12207:2008 CMMI, MoProSoft, MPS.BR, ISO/IEC 29110) 36. 2.2.1 ISO 9001 La norma ISO 9001, es una norma internacional que se aplica a los sistemas de gestión de calidad; se concentra principalmente en los procesos usados para producir un servicio o producto y proporciona el marco necesario para supervisar y mejorar el rendimiento de cualquier área de negocio. 24 2.2.2 ISO/IEC 12207: 2008 Es el estándar internacional que establece un marco común para los procesos del ciclo de vida del software. Contiene procesos, actividades, y tareas que se van a aplicar durante la adquisición de un producto o servicio de software y durante el suministro, desarrollo, operación, mantenimiento y retiro de los productos de software.33 El propósito de esta Norma Internacional es proporcionar un conjunto definido de procesos para facilitar la comunicación entre compradores, proveedores y otros interesados en el ciclo de vida de software. 33 La Norma no detalla los métodos o procedimientos de los procesos del ciclo de vida para cumplir los requerimientos y los resultados de un proceso 33. No detalla la documentación en cuanto a nombre, formato, contenido explícito y soportes de grabación; se puede requerir el desarrollo de documentos similares, y estas decisiones se dejan al usuario de la Norma 33. La Norma no tiene la intención de entrar en conflicto con las políticas, los procedimientos de cualquier organización, y normas o con las leyes y reglamentos nacionales 33. La Norma agrupa siete grupos de procesos que se pueden realizar durante el ciclo de vida de software: 33 a) Procesos de Acuerdo b) Procesos de Habilitación de Proyecto organizacionales c) Procesos de Proyectos d) Procesos Técnicos e) Procesos de Implementación de Software 11 f) Procesos de Soporte de Software g) Procesos de Reutilización de Software Cada uno de los procesos del ciclo de vida de software se describe en términos de su propósito, resultados esperados, actividades y tareas que se deben realizar para alcanzar esos resultados. 33 2.2.3 CMMI Capability Maturity Model Integration (CMMI) es un modelo que proporciona las mejores prácticas para ayudar a las organizaciones a mejorar sus procesos, habilidad para gestionar el desarrollo, adquisición y mantenimiento de productos o servicios 11. Es el modelo internacionalmente más reconocido para la industria de software 11, fue creado por el Sofware Engineering Institute (SEI) a pedido del Departamento de Defensa de los EEUU 11. CMMI tiene seis niveles de capacidad, cada uno es una capa base para la mejora de procesos, se denominan por los números del 0 al 5 23. 0. Incompleto 1. Realizado 2. Gestionado 3. Definido 4. Cuantitativamente Gestionado 5. Optimización Nivel de capacidad 0: Incompleto Un proceso incompleto es un proceso que, o bien no se realiza, o se realiza parcialmente. Al menos una de las metas específicas del área de proceso no se satisface y no existen metas genéricas para este nivel, ya que no hay ninguna razón para institucionalizar un proceso realizado parcialmente. Nivel de capacidad 1: Realizado Un proceso realizado es un proceso que lleva a cabo el trabajo necesario para producir productos de trabajo. Se satisfacen las metas específicas del área de proceso. Nivel de capacidad 2: Gestionado Un proceso gestionado es un proceso realizado que se planifica y ejecuta de acuerdo con la política; emplea personal cualificado que tiene los recursos adecuados para producir resultados controlados; 12 involucra a las partes interesadas relevantes; se monitoriza, controla y revisa; y se evalúa la adherencia frente a la descripción de su proceso. Nivel de capacidad 3: Definido Un proceso definido es un proceso gestionado que se adapta a partir del conjunto de procesos estándar de la organización de acuerdo a las guías de adaptación de la organización; tiene una descripción de proceso que se mantiene y que contribuye a los activos de proceso de la organización con experiencias relativas a procesos. Capacidad Nivel 4: Cuantitativamente Gestionado Un proceso gestionado cuantitativamente es un proceso definido (nivel de capacidad 3) que se controla utilizando técnicas cuantitativas estadísticas y otras. Los objetivos cuantitativos para la calidad y el rendimiento del proceso se establecen y se utilizan como criterios en la gestión del proceso. La calidad y rendimiento de los procesos se entiende en términos estadísticos y se gestionan a lo largo de la vida del proceso 17. Capacidad Nivel 5: Optimización Un proceso de optimización es un proceso gestionado cuantitativamente que se mejoró, basado en la comprensión de las causas comunes de la variación del proceso inherente en el proceso. Se centra en la mejora continua del desempeño de los procesos a través de ambas mejoras incrementales e innovadoras. Tanto los procesos definidos y conjunto de procesos estándar de la organización son los objetivos de las actividades de mejora 17. El modelo CMMI se clasifica en 5 niveles de madurez 23: Inicial o Nivel 1: el proceso de software es impredecible, sin control y reactivo. El éxito de los proyectos depende del talento de los individuos. Repetible o Nivel 2: la principal diferencia entre este nivel y el anterior es que el proyecto es gestionado (costo, calendario, funcionalidad), y controlado durante el desarrollo del mismo. Los procesos existentes hacen que se puedan repetir los éxitos en proyectos de similares características. Definido o Nivel 3: existe un proceso de software documentado y estandarizado dentro de la organización. Todos los proyectos utilizan una versión a medida del proceso. Cuantitativamente Gestionado o Nivel 4: se establecen objetivos cuantitativos de calidad y performance, y son usados como criterios para administrar los procesos. Tanto el proceso como los productos se entienden y controlan cuantitativamente. 13 Optimizado o Nivel 5: existe una mejora continua del proceso software, basada en la realimentación cuantitativa del proceso y en la puesta en práctica de ideas y tecnologías innovadoras. El país líder en aplicar el estándar CMMI es la India, que tiene la mayor cantidad de empresas certificadas en CMMI 4 y 5; seguido por Canadá y China 2. El Perú también desarrolla y exporta software y cuenta con entidades certificadas en CMMI v1.3: en nivel 5 de madurez como IBM, en nivel 3 de madurez como COSAPI, GMD, Everis Perú, Telefónica, entre otros; y en nivel 2 de madurez como el Banco Central de Reserva del Perú y la Universidad Privada Antenor Orrego 21. Cabe destacar que estas entidades han sido evaluados en CMMI en algunos de sus procesos, cumpliendo con determinado nivel de CMMI 59. 2.2.4 MoProSoft Modelo de Procesos para la Industria de Software (MoProSoft), desarrollado para la industria mexicana y basado en la ISO/IEC 9001:2000, ISO/IEC 15504-2:1998 e ISO/IEC 12207:2002 42, fomenta la estandarización de su operación a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. La adopción del modelo permite elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad 42. MoProSoft agrupa los procesos de una organización en tres grandes categorías: (i) Alta Dirección que contiene el proceso de Gestión de Negocios; (ii) Gerencia que está integrada por los procesos de Gestión de Procesos, Gestión de Proyectos y Gestión de Recursos y por último, (iii) Operación que está integrada por los procesos de Administración de Proyectos Específicos, Desarrollo y Mantenimiento de Software.42 2.2.5 MPS.BR “Melhoria de Processo do Software Brasileiro” o "Mejora de Proceso del Software Brasileño", define un modelo de mejora y evaluación de proceso de software y servicios, dando preferencia a las micro, pequeñas y medianas empresas, de modo que se atiendan sus necesidades de negocio y que sea reconocido nacional e internacionalmente como un modelo aplicable a la industria de software y servicios 54. El modelo MPS establece dos modelos de referencia de procesos, uno para software y otro para servicios, y un proceso/método para evaluación de procesos 54. La Figura 2 presenta el modelo MPS, el cual está dividido en cuatro (4) componentes: Modelo de Referencia MPS para Software (MR-MPS- 14 SW), Modelo de Referencia MPS para Servicios (MR-MPS-SV), Método de Evaluación (MA-MPS) y Modelo de Negocio (MN-MPS). Cada componente está descrito por medio de guías y/o de documentos del Programa MPS.BR 54. Figura 2.1 Componente del Modelo MPS.BR 54 El Modelo de Referencia MPS para Software MR-MPS-SW contiene los requisitos que los procesos de las unidades organizacionales deben cumplir para estar en conformidad con el MR-MPS-SW 54. El Modelo de Referencia MPS para Servicios MR-MPS-SV contiene los requisitos que los procesos de las unidades organizacionales deben cumplir para estar en conformidad con el MR-MPS-SV 54. La Guía de Evaluación contiene el proceso y el método de evaluación MA- MPS, los requisitos para los evaluadores líderes, evaluadores adjuntos e Instituciones Evaluadoras (IA) 54. El Modelo de Negocio MN-MPS describe reglas de negocio para implementación del MR-MPS-SW y del MR-MPS-SV por las Instituciones Implementadoras (II), evaluación siguiendo el MA-MPS por las Instituciones Evaluadoras (IA), organización de grupos de empresas por las Instituciones Organizadoras de Grupos de Empresas (IOGE) para implementación del MR-MPS-SW y del MR-MPS-SV y evaluación MA-MPS, certificación de Consultores de Adquisición (CA) y programas anuales de entrenamiento del MPS por medio de cursos, pruebas y workshops 54. 2.2.6 ISO/IEC 29110 La ISO/IEC 29110 es un conjunto de normas e informes técnicos que se ha desarrollado para entidades pequeñas (VSE – Very Small Entities). La 15 industria del software mundial reconoce el valor de las aportaciones de productos y servicios de las Pequeñas Organizaciones (OP); Una OP es una entidad (empresa, organización, departamento o proyecto) conformada por hasta 25 personas 26. La ISO / IEC 29110 consta de las siguientes partes 26: Parte 1: Resumen (Informe Técnico) Parte 2: Framework y taxonomía Parte 3: Guía de evaluación (Informe Técnico) Parte 4-1: Especificaciones de perfil: Grupo de perfil genérico Parte 5-1-2: Gestión y guía de ingeniería: Grupo de perfil genérico La guía proporciona los procesos de gestión de proyectos y procesos de implementación de software, integra prácticas basadas en la norma ISO / IEC 12207:2008 26. El proceso de gestión de proyectos establece y lleva a cabo de forma sistemática las tareas del proyecto de implementación de software, lo que permite cumplir con los objetivos del proyecto. Mientras que el proceso de implementación del software es la realización sistemática de análisis, identificación de componentes de software, construcción, integración, pruebas y entrega de productos de software 26. Esta norma fue adoptada como NTP-ISO/IEC 29110 que proporciona una Guía de Gestión e Ingeniería para el Perfil Básico de las Pequeñas Organizaciones (PO) 19. 2.3 Métodos de evaluación de procesos En esta sección se introducen conceptos de los diferentes modelos de evaluación tales como: ISO/IEC 15504, SCAMPI y EVALPROSOFT, este último es el modelo de evaluación especial para aquellas organizaciones que utilizaron MOPROSOFT como modelo de procesos para su implantación 58 . 2.3.1 ISO/IEC 15504 La ISO/IEC 15504 es una norma internacional para establecer y mejorar la capacidad y madurez de los procesos de las organizaciones 32. Esta norma, denominada “tecnologías de información: proceso de evaluación”, está constituida por diez partes, de los cuales se describirán los 5 primeros por asociarse al tema 25. 15504-1 Conceptos y Vocabulario: Proporciona una introducción general a los conceptos de la evaluación de los procesos y un glosario de términos relacionados 28. 16 15504-2 Realización de la Evaluación: Guía para la evaluación del proceso y la aplicación del proceso de evaluación para el mejoramiento y determinación de la capacidad; precisa los requisitos mínimos para realizar una evaluación que asegure un nivel de consistencia y capacidad de repetición, y que los resultados de la evaluación sean objetivos, imparciales, repetibles, consistentes y representativos 29. 15504-3 Guía para la Realización de la Evaluación: Proporciona una guía para interpretar los requisitos a la hora de realizar una evaluación 30. 15504-4 Guía sobre el uso para la Mejora del proceso y la Determinación de la Capacidad del Proceso: Identifica la Evaluación del proceso como una actividad que puede ser realizada como parte de una iniciativa de mejora de procesos o como parte de un enfoque de determinación de la capacidad. El propósito de la mejora de los procesos es mejorar de forma continua la eficiencia y efectividad de la organización 31. El objetivo de la determinación de la capacidad es identificar las fortalezas, debilidades y riesgos de los procesos seleccionados respecto a un requisito particular especificado a través de los procesos utilizados y de su alineamiento con las necesidades de negocio 31. 15504-5 Un Ejemplo de Modelo de Evaluación de Procesos: Contiene un ejemplo de un modelo para realizar la evaluación de los procesos basados en el modelo de procesos de referencia definido en el estándar ISO/IEC 12207:2008. Una evaluación se lleva a cabo utilizando un modelo de evaluación de procesos relacionado con uno o más modelos de procesos de referencia 32. La ISO/IEC 15504-5 posee una arquitectura basada en dos dimensiones 32: La dimensión de proceso: Se caracteriza por los propósitos de proceso (objetivos de medición esenciales de un proceso) y el resultado esperado del proceso (la indicación de su finalización exitosa). La dimensión de capacidad: Esta dimensión define una escala de medida para determinar la capacidad de cualquier proceso. Consta de 6 niveles de capacidad:  Nivel 0 – Incompleto: Se caracteriza por un incumplimiento general para lograr el propósito del proceso.  Nivel 1 – Realizado ó Desempeñado: Se caracteriza por el logro de manera general del propósito del proceso.  Nivel 2 – Gestionado: Se caracteriza por la identificación de la calidad aceptable con definición de tiempos y recursos. Los 17 productos del trabajo están de acuerdo con los estándares especificados y los requerimientos.  Nivel 3 – Establecido ó Consolidado: Se caracteriza por la gestión y el desempeño del proceso usando el proceso estándar basado en principios estables de ingeniería de software.  Nivel 4 – Predecible: Se caracteriza por la consistencia de su desempeño en la práctica con límites de control definidos para alcanzar sus objetivos de proceso definido.  Nivel 5 - En optimización: Se caracteriza por la optimización del desempeño del proceso para encontrar las necesidades de negocio actuales y futuras, y por el grado de repetición que el proceso alcanza encontrando sus objetivos de negocio definidos. Cada nivel de capacidad consta de una serie de atributos, los cuales se miden de acuerdo al porcentaje de alcance, los porcentajes que se muestran a continuación son referenciales 32:  N (No alcanzado) 0% a 15%.  P (Parcialmente Alcanzado) >15% a 50%.  L (Ampliamente Alcanzado) >50% a 85%.  F (Totalmente Alcanzado) >85% a 100%. 2.3.2 SCAMPI El Standard Appraisal Method for Process Improvement (SCAMPI) es el método de Evaluación de CMMI para la mejora de procesos, satisface los requerimientos de evaluación de CMMI y está basado en los requisitos para evaluación de proceso de la ISO/IEC 15504 55. La definición de SCAMPI describe los requisitos, las actividades y las prácticas relacionadas con cada uno de los procesos que componen el método SCAMPI y determina tres clases de evaluación (A, B y C) 55.  SCAMPI Evaluaciones tipo C (Enfoque): Examinan los procesos de la organización de forma menos rigurosa, no proporciona puntuación sobre el nivel de madurez. Evalúa áreas de riesgo con recolección básica de datos y es también el modelo de evaluación menos exigente en el levantamiento de información y requisitos. Es el más rápido y de menor costo. 18  Evaluaciones tipo B (Despliegue): Estas evaluaciones son el punto intermedio entre las evaluaciones tipo C y A, es decir son más rigurosas que las evaluaciones tipo C y a la vez más flexibles que las evaluaciones tipo A, no proporcionan puntuación sobre el nivel de madurez, aunque ya exigen el uso de exámenes de resultados o artefactos obtenidos al desplegar los procesos en proyectos seleccionados en una unidad de la organización. Es útil previo a la implantación masiva de nuevos procesos.  Evaluaciones tipo A (Institucionalización): Son las evaluaciones más exhaustivas y rigurosas, son las únicas que brindan puntuación sobre el nivel de madurez de la organización, permiten determinar si la organización puede implementar con mayor nivel de confianza los procesos. 2.3.3 EvalProSoft El modelo de evaluación EvalProSoft está desarrollado para ser utilizado en organizaciones vinculadas a la industria del Software y nace como un esfuerzo conjunto para ser adaptado a las Pequeñas y Medianas Empresas; aplicado a aquellas organizaciones que han utilizado a MoProSoft como modelo de referencia para la implantación de procesos 44. El método de evaluación EvalProSoft está basado en los requisitos expresados en la norma ISO/IEC15504-2. Los procesos se miden en base a sus capacidades. La capacidad de un proceso se evalúa en una escala entre 0 y 5, donde el 0 se asocia al nivel de capacidad más bajo, y significa que no se alcanza el propósito del proceso. Por otro lado, el valor 5 como capacidad del proceso se asocia al nivel más alto e indica que se logran las metas de negocio actuales y proyectadas a través de la optimización y mejora continua del proceso 44. La medición de la capacidad de un proceso se obtiene a través de un conjunto de atributos del proceso, los cuales son utilizados para establecer la capacidad de un determinado proceso 44. El grado de cumplimiento del atributo del proceso se califica usando una escala ordinal, tomando como referencia los porcentajes de la ISO/IEC15504 -2 44. 2.4 Métodos de Mejora de Procesos de Software 19 Un modelo de mejora de procesos brinda un esquema de trabajo sostenido para alcanzar el desarrollo y evolución de las capacidades de los procesos, teniendo como base un perfil inicial de los procesos 56. Adicionalmente, para una organización (cualquiera sea el rubro) es importante implementar un proceso de estrategia de mejoramiento para producir un proceso de software bien definido 51. Existen diferentes modelos de mejora de procesos, de los cuales en esta sección se describirán: Agile SPI, IDEAL y PMCOMPETISOFT. 2.4.1 Agile SPI Agile SPI - Process es un proceso ágil y liviano de mejora de procesos de software, el cual puede ser utilizado como guía para la ejecución de un programa de mejora de procesos de software en pequeñas y medianas empresas (PyMES) 52. Liviano porque empresas como las pymes poseen ciertas características como: bajos recursos, bajo número en recursos humanos, disponibilidad económica limitada, etc 52. Agile SPI – Process es un proceso, iterativo e incremental y está basado en casos de mejora 52. Tiene la característica de poder arrojar resultados rápidos de mejora, dado que permite crear mini-programas de mejora que abarcan casos de mejora dentro de un programa de mejoramiento global. Los componentes del modelo integral de mejoramiento Agile SPI son 52: • Agile SPI – Process, establece una guía a un programa de mejora de procesos. Cuenta con los elementos básicos para hacer posible que pymes se adecuen a un proceso de desarrollo acorde a sus necesidades 52. • Agile SPI – Light Quality Model (modelo de calidad liviano), que integra proceso y producto, y que guía la organización de las personas y los equipos, las disciplinas y las áreas de trabajo asociadas a la definición, aplicación y mejora del proceso hacia un nivel de madurez definido 52. • Agile SPI – Light Evaluation Model (modelo de evaluación liviano), que permite identificar y diagnosticar problemas de la industria en cuanto al proceso y que permite trazar unos planes de mejora de acuerdo a un estándar de calidad definido 52. • Agile SPI – Light Metrics Model (modelo de medida liviano), que permite medir el desempeño del proceso en los proyectos en los cuales es aplicado, mejorar las estimaciones de los proyectos a través de la medida del esfuerzo. 52. • Agile SPI – Framework (marco conceptual y tecnológico para la definición, visualización y aplicación de procesos). Este marco permite 20 relacionar los elementos del proceso con los elementos del modelo de calidad, con el modelo de evaluación y con el modelo de medida 52. Agile SPI está compuesto por 5 fases, las cuales se muestran en la Figura 3: Instalación, Diagnóstico, Formulación, Mejora y Revisión del Programa y se describen a continuación 52. 1. Instalación, se crea una propuesta de mejora de acuerdo a las necesidades del negocio además de diseñar la infraestructura de gestión, donde se describe cómo se organizarán las personas, teniendo en cuenta un equipo de gestión, de tecnología de procesos y de mejora 52. 2. Diagnóstico, en esta fase los equipos de gestión y de tecnología de procesos realizan actividades de valoración para determinar el estado de los procesos en la organización y luego realizar un análisis de los resultados estableciendo de esta forma posible casos de mejora y estructurar un plan general de mejora 52. 3. Formulación, el equipo de mejora se enfoca en los casos de mejora críticos, de acuerdo a los resultados obtenidos en la fase anterior, se realizan las primeras iteraciones de mejora las cuales se toman como muestra y estimación de esfuerzo, costos y tiempo que tomará ejecutar el resto de casos de mejora. Con estas estimaciones se podrá realizar la planificación de las demás iteraciones de mejora 52. 4. Mejora, en esta fase se gestionan y ejecutan todos los casos de mejora de acuerdo a la planificación realizada en la fase de formulación 52. 5. Revisión del Programa, el equipo de gestión realiza un análisis de todas las fases anteriores utilizando las lecciones aprendidas y las métricas desarrolladas para el cumplimento de los objetivos, como base del conocimiento para las personas que tendrán a cargo el siguiente ciclo de mejora. Con toda la información obtenida en el ciclo de mejora se debe evaluar el trabajo realizado, métodos utilizados, infraestructura, etc. y corregir los errores cometidos en la ejecución de la mejora 52. Figura 2.2 Fases del Agile SPI Process 52 2.4.2 IDEAL 21 Es un modelo de mejora de procesos de software 46,que se puede utilizar como guía para gestionar un programa SPI 38. IDEAL fue propuesto por el Software Engineering Institute y también está enfocado en la mejora de procesos de la organización, sirve como un mapeo para iniciar, planificar e implementar acciones de mejora de procesos. Sin embargo, es necesario indicar que está enfocado a organizaciones vinculadas a la industria de Software 57. Está compuesto de cinco fases (ver figura 4) para la realización exitosa de un ciclo de mejora de proceso, la primera letra de cada fase (en inglés) es una de las letras que conforma el nombre del modelo de mejora de procesos IDEAL 6. Se describe a continuación las fases: • Iniciación: Esta fase del modelo es el punto inicial, aquí es donde son establecidos la infraestructura de mejoramiento inicial, además de los roles, las responsabilidades y los recursos. Es en esta fase donde se definen las metas principales, las cuales son establecidas de acuerdo a las necesidades del negocio de la organización 6. • Diagnóstico: Esta fase se caracteriza porque es en este momento del ciclo de mejora donde se define el estado inicial de la organización, es decir, se identifican las debilidades y fortalezas mediante el uso de evaluaciones 6. • Establecimiento: En la fase de establecimiento, los problemas que la organización ha identificado, como resultado de la fase previa, son priorizados y clasificados. Por otro lado, en esta fase la meta global, identificada en la fase de iniciación, es descompuesta en varias metas 6. • Actuación: Es en esta fase donde las soluciones de mejoramiento establecidas son ejecutadas. Los planes son desarrollados para ejecutar pilotos de prueba y de evaluación 6. • Aprendizaje: En esta fase se miden los logros alcanzados y se detallan las ocurrencias y percances a manera de Lecciones Aprendidas para que puedan servir como guía base en los próximos ciclos de mejora 6. 22 • Aprendizaje: En esta fase se miden los logros alcanzados y se detallan las ocurrencias y percances a manera de Lecciones Aprendidas para que puedan servir como guía base en los próximos ciclos de mejora 6. Figura 2.3 Fases del modelo IDEAL 6 2.4.3 PMCOMPETISOFT El modelo de mejora de COMPETISOFT (PMCOMPETISOFT) tiene como propósito mejorar los procesos de la organización en función de sus objetivos de negocio, así como ayudar a conducir la mejora de procesos de software en las pequeñas organizaciones, a través de la definición de una guía para implementar paso a paso la mejora de procesos 9. Está basado en Agile SPI (Software Process Improvement) y está compuesto de 5 macro-actividades: Instalación, Diagnóstico, Formulación, Mejora y Revisión 9. • Instalación del ciclo: Se crea o actualiza una Propuesta de Mejora alineada con la planeación estratégica de la organización plasmada en el Plan Estratégico. La propuesta debe ser aprobada y divulgada para garantizar, de esta manera, la asignación de los recursos necesarios y el compromiso de los involucrados. • Diagnóstico de procesos: Se realiza la actividad de evaluación interna de procesos para conocer el estado general de los procesos de la organización y analizar los resultados con el objetivo de establecer las 23 oportunidades de mejora de un proceso y su prioridad de mejora. Se realiza una planificación preliminar y general del ciclo de mejora, determinando una ruta de ejecución de la mejora. • Formulación de mejoras: Se planifica el ciclo de mejora y define la estrategia a seguir para mejorar el proceso seleccionado. • Ejecución de mejoras: Se gestionan y ejecutan los casos de mejora de acuerdo a los planes establecidos. Si la planificación se ha desarrollado satisfactoriamente se aceptan e institucionalizan los nuevos procesos en la organización. • Revisión del ciclo: Se corrigen o ajustan todos los elementos relacionados con la ejecución de cada una de las iteraciones de mejora. Se aplica nuevamente la evaluación interna de los procesos para cuantificar las mejoras que se han realizado. Al final se hace un análisis post-mortem del trabajo realizado en todo el ciclo de mejora. 2.5 COMPETISOFT En el proyecto COMPETISOFT estuvieron involucrados 13 países, incluido el Perú; fue un proyecto financiado por el Programa Iberoamericano de Ciencia y Tecnología para el Desarrollo, que implicó un organismo de normalización y certificación, más de 10 empresas pequeñas y 27 grupos de investigación de 13 países de América, que han sumado el esfuerzo de involucrados, el conocimiento de procesos adquiridos, el proceso de mejora realizada con la base del “knowhow” y beneficios descritos por las empresas 9. Dicho proyecto tuvo como objetivo general el incrementar el nivel de competitividad de las pymes Iberoamericanas productoras de software, mediante la creación y difusión de un marco metodológico común que ajustado a sus necesidades específicas, pueda llegar a ser la base para establecer un mecanismo de evaluación y certificación de la industria del software reconocido en toda Iberoamérica 9. COMPETISOFT define un patrón de procesos aplicable a cualquier organización desarrolladora de software y presenta tres partes 9: El modelo de referencia está basado en MOPROSOFT y agrupa los procesos en tres categorías principales: Alta dirección, Gestión y Operación; el modelo de evaluación está basado en el método de evaluación EvalProSoft e ISO/IEC 15504-2; el modelo de mejora está basado en Agile SPI 43. 24 2.6 COMPETISOFT – PERU Los estudiantes de pregrado y bachilleres de la especialidad de Ingeniería Informática de la Pontificia Universidad Católica del Perú bajo la supervisión de un asesor y director del proyecto integraron el Grupo de Investigación y Desarrollo en Ingeniería de Software (GIDIS); cada uno de ellos ha participado en diferentes empresas peruanas desarrolladoras de software para realizar la evaluación y mejora de los procesos utilizando los modelos relacionados al Proyecto Competisoft 36. El proyecto en mención forma parte de un esfuerzo Iberoamericano que busca elevar el nivel de competitividad de las pequeñas y medianas empresas de la industria de software, a través del mejoramiento de sus procesos, lo cual se traduce en la realización de pruebas controladas de implantación de un marco metodológico de mejora de procesos adaptado a la realidad de cada empresa 36. Este proyecto se desarrolló del año 2007 hasta el 2011 y estuvo conformado por 3 fases. Cada fase constituye un proyecto independiente, la fase 1 se realizó a través del Proyecto Internacional financiado por CYTED, la fase 2 sirvió para realizar la replicación a otras ciudades y la fase 3 para la certificación de empresas 12. En la Fase 2, GIDIS-PUCP ha participado en COMPETISOFT-Perú 2, en coordinación con la Universidad Nacional San Agustín de Arequipa (UNSA), Universidad Católica Santa María (UCSM) y la Universidad Nacional de Trujillo (UNT), en el marco de colaboración de la Red Peruana de Universidades (RPU). COMPETISOFT – Perú 2 36; como en su primera etapa, busca la mejora de procesos software en un grupo de pymes que desarrollan software 39. El proyecto permitió obtener un conjunto de beneficios y resultados tanto para empresas, como para profesionales y académicos. Tuvo buena aceptación en las empresas y estudiantes que vieron una oportunidad interesante para desarrollar distintas habilidades 12. 2.7 PACIS PACIS es el Programa de Apoyo a la Competitividad de la Industria del Software, proyecto cofinanciado por el Banco Interamericano de Desarrollo BID/FOMIN, y ejecutado por la Cámara de Comercio de Lima con el apoyo de la Asociación Peruana de Productores de Software (APESOFT) 14. 25 Este Programa se constituyó con la finalidad de coadyuvar en el fortalecimiento del conocimiento científico, cultural, educativo y tecnológico en la sociedad del conocimiento, coordinando e intercambiando experiencias de investigación, docencia y capacitación. Sus objetivos fueron promover la divulgación del conocimiento científico y cultural en todos los sectores de la sociedad; desarrollar políticas de Educación, dando énfasis a la educación continua; realizar, fomentar y promover estudios y proyectos de investigación científica, proyectos de inversión social y económica, programas de capacitación y publicación de textos y/o revistas orientadas a apoyar el desarrollo de la sociedad del conocimiento 35. Desde el 2004 al 2007 se condujo a formar empresas en sistemas de calidad CMMI 14. 2.8 RELAIS La Red Latinoamericana de la Industria del Software (RELAIS), es una organización regional actualmente coordinada por cuatro importantes instituciones de Brasil, Colombia, México y Perú. Su objetivo principal es aumentar la competitividad de la industria del software en América Latina y el Caribe (ALC) promoviendo la calidad en el proceso de producción y adquisición de software y desarrollo de los servicios de tecnología de la información y favoreciendo el clima de negocios 49. La RELAIS promueve la diseminación en los países participantes de los modelos de calidad de software para pymes desarrollados con éxito en Brasil y México, la creación y el posicionamiento de la Red como entidad referente en temas de ingeniería y calidad de software en la Región 49. La Red trabaja con los Modelos de Mejora de procesos 49:  Melhoria de Processo de Software (MPS) elaborado en el 2006 en Brasil.  Modelo de Procesos para la Industria de SW (MOPROSOFT) elaborado en México en el 2002. También incluye las Certificaciones ITMARK, esquema de certificación Europeo diseñado para pymes de TI, que abarca las áreas de Gestión de Negocio, Ingeniería de Software, Sistemas y Servicios y Gestión de Seguridad 49. Al 2013 se consolida la RELAIS Internacional como Entidad Regional sin fines de lucro que da sustentabilidad al Proyecto, continuidad y expansión al conocimiento, los servicios/soluciones y la comunidad de aprendizaje TIC, toda vez que existen unas 60 millones de pymes en Latinoamérica y el Caribe, de las cuales un gran porcentaje aún no han despertado al mundo tecnológico. “Uno de los diferenciales de la Red es que se ocupa del software de manera integral: del lado de quien lo 26 produce y del lado de quien lo utiliza. Para la oferta también existe un potencial de crecimiento enorme para Latinoamérica 3. La Red Internacional proyecta a continuar con la incorporación y mapeo de todos aquellos Modelos u otros Instrumentos que la industria haya aceptado, lo cual resultará en un crecimiento ordenado de Modelos e Instrumentos para incrementar la calidad en beneficio de las empresas que producen software y también de quienes lo utilizan. Se está considerando la incorporación del Modelo CMMI y de la ISO/IEC 29110 53. 27 Capítulo 3 Empresa de estudio En este capítulo se describe a la empresa, cuándo fue creada, qué servicios realiza y los objetivos que persigue. 3.1 Descripción de la empresa Para evaluar la aplicación de la ISO/IEC 12207:2008 se consideró una micro empresa peruana, a la cual de ahora en adelante se denominará X a fin de garantizar la confidencialidad de la misma. X es una microempresa peruana, que orienta sus servicios y soluciones de modo horizontal; orientada a la prestación de servicios de consultoría, gestión de proyectos, mejora de procesos de gestión; desarrollo e implementación de sistemas de información, informáticos y comunicaciones, soporte de gestión e informático; comercialización de equipos, insumos informáticos y de comunicaciones; exportación e importación de productos y servicios de gestión, informáticos, software y comunicaciones. X fue constituida a finales de Octubre del 2010, y a la fecha cuenta con 8 personas prestando sus servicios en la organización, los cuales conforman la siguiente estructura organizacional: Figura 3.1 Estructura Organizacional Siendo los siguientes roles: • 1 Gerente General • 1 Jefe de proyectos • 2 Analistas Programadores 28 • 2 Analistas QA • 1 Especialista en Procesos y Seguridad Informática • 1 Contador Nota: El Gerente General a su vez desempeña el rol de Jefe de Proyectos y forma parte de la Gerencia de Proyectos. Los productos y servicios que realizó X desde su creación incluyen:  Diseño y mejoramiento de procesos, en servicios de 2 meses aproximadamente.  Análisis y diseño de sistemas de información en general, en servicios de 2 meses aproximadamente.  Implementación de sistemas de información para el Monitoreo y Control, en servicios de 3 meses aproximadamente.  Desarrollo de software a la medida para el Registro en Programas y Proyectos para el Ministerio de la Mujer y Poblaciones Vulnerables, Ministerio de Desarrollo e Inclusión Social, Ministerio de Justicia, Gobiernos Regionales, en servicios de 3 meses aproximadamente.  Personalización o adecuaciones de aplicativos para el Sector Público, en servicios de 3 meses aproximadamente.  Capacitación y asistencia técnica, en servicios de 3 días a 1 semana. La empresa en estudio, se proyecta a ser una empresa perteneciente a la APESOFT, que a través del CITE Software, puede acceder a capacitación especializada y asistencia técnica en la implementación de sistemas de calidad como ISO 9000 e ISO/IEC 12207. 3.2 Objetivos de la Empresa Como parte del proceso de inducción en la empresa, se consideró efectuar un levantamiento de información para determinar los objetivos de negocio de X, los cuales no estaban formalizados ni documentados. Se obtuvieron a través de entrevistas realizadas al gerente general los siguientes objetivos: 1. Mejorar el flujo y rentabilidad de la empresa 2. Entregar productos y/o servicios de calidad 3. Minimizar el tiempo en desarrollo 4. Generar confianza y fidelización de clientes 5. Ampliar el desarrollo de productos y/o servicios al sector privado 6. Generar alianzas con socios estratégicos 29 7. Mantener un staff de profesionales altamente capacitados en las últimas tecnologías 30 Capítulo 4 Desarrollo del Proyecto En este capítulo se detalla; cómo se seleccionaron los procesos a ser evaluados, cómo se realizó la definición de medida de rendimiento y evaluación de los procesos priorizados. Los procesos elegidos fueron mejorados, los cuales se aplicaron a un proyecto que realizó la empresa. 4.1 Procesos a ser evaluados Durante las entrevistas, se consideró todos los procesos de la ISO/IEC 12207:2008, luego se determinaron aquellos procesos relevantes para conseguir el cumplimiento de los objetivos de negocio. Se formularon preguntas en base a la norma ISO/IEC 15504-5. Las respuestas obtenidas fueron registradas en un cuadro en la que se determina la frecuencia de desarrollo de actividades y el grado de cumplimiento por cada uno de los procesos evaluados. 4.1.1 Técnica de obtención de datos Para la obtención de los datos usados para la evaluación, se realizaron entrevistas al personal de la empresa utilizando un cuestionario como guía, obtenido en base a la ISO/IEC 15504-5. El objetivo de la evaluación fue determinar el nivel de cumplimiento de los procesos. Se presentan los cuadros de evaluación, cálculo y resultados en los Anexos N° 01, 02 y 03. 4.1.2 Resultados obtenidos Se presentaron los resultados obtenidos al gerente general, el que a su vez desempeña el cargo de jefe de proyectos. Estos resultados detallan la situación encontrada en la empresa X, que fue obtenida durante la evaluación realizada con los responsables de los procesos. 31 4.1.3 Evaluación inicial Para realizar la evaluación se utilizó la metodología empleada por el Proyecto COMPETISOFT-PUCP, la que utiliza cuadros de evaluación que permiten seleccionar qué procesos deben ser priorizados. En la evaluación inicial se consideró:  Aquellos problemas que podrían afectar los objetivos de negocio.  Los procesos que afecten los objetivos de negocio.  Los procesos que determinan mayor impacto en la solución de problemas. En base a dichos resultados y en coordinación con el equipo de la empresa X; se seleccionaron los procesos a mejorarse. a) Priorización de procesos: Objetivos de Negocio vs. Problemas de Negocio Se realizaron entrevistas con el Gerente General de la empresa, para relevar los objetivos del negocio que se determinaron en 3.2. Asimismo, se realizaron entrevistas con los Gerentes, los cuales identificaron cuáles eran los problemas que afectaban el alcance y cumplimiento de los objetivos estratégicos que trazan la visión de la empresa. Finalmente con los gerentes se determinó el peso, para lo cual se empleó la técnica de grupo nominal; el peso es el valor de importancia que tiene el objetivo para la evolución de la empresa, como factor importante a considerar para analizar los problemas más significativos en la empresa. 32 Cuadro 4.1: Objetivos de Negocio vs. Problemas de Negocio 1 2 3 4 5 6 Pocas utilidades o bajos ingresos para la empresa Personal no tiene 100% disponible de su tiempo Cambios en la organizaci ón y procesos operativos del Estado No hay posiciona miento de la empresa Demora por parte del cliente en las diferentes etapas del proyecto Mala administra ción del conocimie nto de la organizaci ón Mejorar el flujo y rentabilidad de la empresa 8 16.00% 2 1 2 2 2 2 Entregar productos y/o servicios de calidad 7 14.00% 2 2 2 1 1 1 Minimizar el tiempo en desarrollo 6 12.00% 1 2 2 1 2 2 Generar confianza y fidelizacion de clientes 8 16.00% 1 2 1 2 1 1 Ampliar el desarrollo de productos y/o servicios al sector privado 7 14.00% 2 1 1 2 1 2 Generar alianzas con socios estrategicos 6 12.00% 1 1 1 2 1 1 Mantener un staff de profesionales altamente capacitados en las ultimas tecnologias 8 16.00% 1 2 1 1 1 2 50 1.44 1.58 1.42 1.58 1.28 1.58 Problemas Peso %Peso Objetivos Por tanto, se seleccionaron los 3 problemas con mayor puntaje y de mayor impacto:  Personal no tiene 100% disponible de su tiempo. Es decir no contar con la disponibilidad del 100% del tiempo del personal  No hay posicionamiento de la empresa  "Mala administración del conocimiento de la organización" b) Priorización de procesos: Objetivos de Negocio vs. Procesos ISO/IEC 12207:2008 Se realizaron entrevistas con el Gerente de la empresa, para determinar el impacto de la ejecución de cada uno de los procesos de la ISO/IEC 12207:2008 en el marco del alcance y logro de los objetivos estratégicos del negocio. Se determinó el impacto de cada uno de los procesos con relación a la importancia que tiene el objetivo para la evolución de la empresa. En la evaluación se tomó en cuenta todos los procesos (en la fase inicial de evaluación), es decir los que se encuentran dentro de los Procesos de Contexto del Sistema y Procesos Específicos de Software, ya que estos son los grupos especificados por la ISO/EC 12207:2008. Los resultados y evaluación de cada uno de los mapeos entre proceso y objetivo para la valoración final se realizó de igual manera 33 que la evaluación de los Problemas vs. Objetivos, descritos en la sección anterior. Cuadro 4.2: Objetivos de Negocio vs. Procesos ISO/IEC 12207:2008 34 35 c) Priorización de procesos: Problemas de Negocio vs. Procesos ISO/IEC 12207:2008 Para completar la evaluación de los procesos a ser considerados en el diseño del Plan de Mejora de Procesos, se realizó la evaluación entre los problemas identificados versus los procesos de la ISO/IEC 12207:2008 para identificar cuáles de éstos determinaban mayor impacto en la solución de los problemas que afectaban el mejor desempeño de la empresa, toda vez que los cuadros anteriores objetivos de negocio vs problemas de negocio y objetivos de negocio vs procesos ISO/IEC 12207:2008 permitieron identificar previamente los problemas de negocio y procesos. Se determinó el nivel de impacto de la ejecución de cada uno de los procesos cuya implementación permitiría disminuir la ocurrencia de los problemas identificados en la empresa. Cuadro 4.3: Problemas de Negocio vs. Procesos ISO/IEC 12207:2008 36 37 Se identificaron los 4 procesos que representaban ser los de mayor impacto para disminuir la ocurrencia de los problemas en la empresa a través de la técnica del grupo nominal. Con esta técnica los participantes calificaron los procesos vs objetivos y problemas mediante ponderaciones según orden de importancia (para el caso se calificó del 1 al 3, de menos importante a mas importante). Existiendo 2 procesos que obtuvieron el mismo puntaje (Aceptación de Software y Aseguramiento de la Calidad de Software), mediante consenso el equipo de gerentes y analistas del proyecto determinaron relevante considerar para la mejora, el proceso de Aceptación de Software. Dado los resultados del análisis, la empresa presenta dificultades para gestionar riesgos en proyectos, inconvenientes en la aceptación de software y debilidades en la reutilización de componentes de soluciones. Por ello los procesos a ser mejorados son:  Proceso de Gestión de Riesgos  Proceso de Gestión de Activos de Reuso  Proceso de Aceptación de Software 4.1.4 Seleccionando los procesos para la Propuesta de Plan de Mejora En base a las tres evaluaciones realizadas y resultados obtenidos, se compararon los procesos clasificados en las 2 evaluaciones, que involucran procesos para definir aquellos a ser considerados en la elaboración de la Propuesta de Mejora. Los procesos que requieren atención se obtuvieron de las matrices 38 que involucraban procesos tales como: objetivos-procesos, problemas-procesos y objetivos-problemas, las cuales se presentan a continuación: Objetivos - Procesos • Proceso de Gestión de Riesgos • Proceso de Aceptación de Software • Proceso de Pruebas de Calificación del Software • Proceso de Aseguramiento de la Calidad del Software • Proceso de Gestión de Reuso Problemas - Procesos • Proceso de Gestión de la Calidad • Proceso de Gestión de Riesgos • Proceso de Pruebas de Calificación del Software • Proceso de Aseguramiento de la Calidad del Software • Proceso de Gestión de Reuso Objetivos - Problemas Permite priorizar los procesos a mejorar, ya que estos darán a solución a los problemas más importantes: • Personal no tiene 100% disponible de su tiempo • No hay posicionamiento de la empresa • Mala administración del conocimiento de la organización Entonces se vio por conveniente priorizar la mejora en los siguientes procesos:  Proceso de Gestión de Riesgos  Proceso de Apoyo de Aceptación de Software  Proceso de Gestión de Activos de Reuso La elección de los procesos a priorizar fue decidido por la gerencia, que fue orientada en base al análisis de sus necesidades internas y objetivos prioritarios. También consideró que los procesos restantes podrían mejorarse en una próxima etapa de mejora. Se presenta la necesidad de reforzar la capacidad de la empresa en el proceso de Aceptación de Software, en vista las dificultades para obtener la conformidad de los servicios. Los procesos priorizados fueron evaluados en 2 proyectos diferentes en el que participó la empresa X:  Para el análisis de la situación inicial y propuesta de mejora de los procesos priorizados se tomó el proyecto Z cliente/servidor (3 meses). 39  La implementación de las mejoras se realizó durante el Proyecto del Z Web (3 meses). 4.1.5 Esquema para la definición de la medida de rendimiento de un proceso. Para definir las métricas se tomó como referencia uno de los procesos con características de nivel 1, que establece el estándar ISO/IEC 15504-5 48. Como todos los procesos de la norma tienen la misma estructura, a partir de definir las métricas para un proceso se puede construir las métricas de los demás procesos del modelo de referencia 48. El proceso seleccionado para explicar la definición de medida de rendimiento es de Gestión de Riesgos que será posteriormente desarrollado en el próximo capítulo. Tabla 4.1 Estructura del proceso de Gestión de Riesgos según la ISO/IEC 15504-5 32 ID del proceso MAN.5 Gestión de Riesgos Propósito del proceso El propósito del proceso de gestión de riesgos es identificar, analizar, tratar y controlar los riesgos continuamente. Resultados del proceso Como resultado de la implementación exitosa del proceso de gestión del riesgo: 1) se determina el alcance de la gestión de riesgos a realizar; 2) se definen y aplican las estrategias adecuadas de gestión del riesgo; 3) los riesgos se identifican como se desarrollan durante la realización del proyecto; 4) se determina los riesgos y la prioridad en la que se aplican a los recursos para el tratamiento de estos riesgos; 5) se definen las medidas de riesgo, aplicados y evaluados para determinar los cambios en el estado de riesgo y el progreso de las actividades de tratamiento y 6) se toma el tratamiento apropiado para corregir o evitar el impacto de los riesgos en función de su prioridad, probabilidad y consecuencia u otro umbral de riesgo definido. Prácticas base MAN.5.BP1 : Establecer el alcance de gestión de riesgos . Determinar el alcance de la gestión de riesgos a realizar. [ Resultado: 1 ] MAN.5.BP2 : Definir estrategias de gestión de riesgos . Definir estrategias y riesgos apropiadas medidas para identificar, analizar, tratar y controlar cada riesgo o grupo de riesgos, tanto en el proyecto y el nivel de organización. [ Resultado : 2 , 5 ] MAN.5.BP3 : Identificar los riesgos. Identificar los riesgos del proyecto, tanto inicialmente dentro de la estrategia del proyecto y a medida que se desarrollan durante la realización del proyecto. [ Resultado: 3 ] MAN.5.BP4 : Analizar los riesgos . Analizar los riesgos y aplicar medidas de riesgo para determinar las prioridades. [ Resultado : 4 , 5 ] MAN.5.BP5 : Definir y ejecutar acciones de tratamiento del riesgo . Para cada riesgo (o conjunto de riesgos) definir y 40 realizar las acciones necesarias para reducir los riesgos a un nivel aceptable. [ Resultado : 5 , 6 ] MAN.5.BP6 : riesgos del monitor . Monitorear el estado actual de cada riesgo, determinar los cambios en la situación de riesgo y evaluar la eficacia de las medidas de tratamiento del riesgo. [ Resultado: 5,6] MAN.5.BP7 : Tomar medidas preventivas o correctivas . Cuando se espera que los avances en el riesgo no se consigue la mitigación, medidas preventivas pertinentes para reducir aún más o evitar el impacto de cada riesgo. Cuando la mitigación del riesgo no puede reducir o evitar el riesgo, plan correctivo medidas para resolver los problemas ocasionados por el riesgo . [ Resultado: 6 ] Productos de trabajo Inputs Outputs 07-07 Medidas de Riesgos [Resultado: 5] 08-12 Plan de Proyecto [Resultado: 1] 08-14 Plan de Recuperación [Resultado: 4, 6] 08-19 Plan de Gestión de Riesgos [Resultado: 4, 5 08-19 Plan de Gestión de Riesgos [Resultado: All] 08-20 Plan de Mitigación de Riesgos [Resultado: 6] 08-20 Plan de Mitigación de Riesgos [Resultado: 3, 4] 13-20 Requisito de Acción de Riesgos [Resultado: 4] 13-20 Requisito de Acción de Riesgos [Resultado: 2, 6] 14-02 Registro de Acciones Correctivas [Resultado: 6] 14-08 Sistema de Seguimiento [Resultado: 3, 4, 5, 6] 14-08 Sistema de Seguimiento [Resultado: 2, 3, 4, 5, 6] 15-08 Reporte de Análisis de Riesgos [Resultado 4] 15-09 Reporte de Estado de Riesgos [Resultado 4, 5] Los procesos del estándar ISO/IEC 15504 están compuestos de cinco elementos fundamentales 48: • El propósito del proceso, • Los resultados para la implementación exitosa del proceso, • Las practicas base, que son tareas y/o actividades que se deben realizar para generar un resultado, • Entradas, que son productos de trabajo que están relacionadas con los resultados, y a través de estos con las prácticas base. • Salidas, que son productos de trabajo que están relacionadas con los resultados, y que son indicadores para observar que el proceso cumple el propósito. a) Definición de la métrica Teniendo en cuenta la estructura de los procesos del nivel uno de capacidad del estándar ISO/IEC 15504-5, se puede medir y evaluar la 41 implementación exitosa de ellos basado en sus resultados. Los resultados están relacionados con prácticas base y productos de trabajo 48. Las métricas a nivel del rendimiento del proceso han sido definidas con el objetivo de evaluar el grado de cumplimiento de un proceso en relación al proceso definido. La definición de estas métricas se muestra en las tablas 4.2 y 4.3. Tabla 4.2 Métricas a nivel del rendimiento del proceso 48 Métricas del rendimiento del proceso 1. En función de las prácticas base Métrica Definición NRP_std Número de resultados del proceso software a evaluar definidos por el estándar ISO/IEC 15504-5. NPB_std Número de prácticas base del proceso software a evaluar definidos por el estándar ISO/IEC 15504-5. NPBRi_std Número de prácticas base que contribuyen al logro del resultado i, del proceso software a evaluar definidos por el estándar ISO/IEC 15504-5. PRP Peso de cada uno de los resultados del proceso software a evaluar. PRP = 1 / NRP_std VPBRi_ro Valor de las prácticas base para el resultado i, realizadas o llevadas a cabo por la organización. Se obtiene a partir de un instrumento de recolección de información. GCRi (PB) Grado de cumplimiento del resultado i, en función de las prácticas base. GCRi (PB) = VPBRi_ro / NPBRi_std MRP (PB) Medida del rendimiento del proceso en función de las prácticas base. n ∑ MRP (PB) = PRP * i =1 GCRi (PB) 2. En función de los productos de trabajo Métrica Definición Pregunta 42 NPTE_std Número de productos de trabajo de entrada del proceso software a evaluar definidos por el estándar ISO/IEC 15504-5. 5 NPTS_std Número de productos de trabajo de salida del proceso software a evaluar definidos por el estándar ISO/IEC 15504-5. 9 NPTERi_std Número de productos de trabajo de entrada del resultado i, del proceso software a evaluar definidos por el estándar ISO/IEC 15504-5. 9 NPTSRi_std Número de productos de trabajo de salida del resultado i, del proceso software a evaluar definidos por el estándar ISO/IEC 15504-5. 22 NTPTRi Número total de productos de trabajo del resultado i. NTPTRi = NPTERi_std + NPTSRi_std 31 NPTRi_ro Número de productos de trabajo para el resultado i, realizadas o llevadas a cabo por la organización. Se obtiene a partir de un instrumento de recolección de información. 14 GCRi (PT) Grado de cumplimiento del resultado i, en función de los productos de trabajo. GCRi (PT) = NPTRi_ro / NTPTRi 3.09 MRP (PT) Medida del rendimiento del proceso en función de los productos de trabajo. n ∑ MRP (PT) = PRP * i =1 GCRi (PT) 0.51 Los resultados de los procesos en el estándar ISO/IEC 15504, están relacionados con las prácticas base y con los productos de trabajo. Para obtener una medida del rendimiento del proceso se realizará lo indicado en la Tabla 4.3 48: Tabla 4.3 Medida del rendimiento del proceso 48 Métricas del rendimiento del proceso En función de las prácticas base y los productos de trabajo 43 Métrica Definición MRP Medida del rendimiento del proceso. MRP = MRP(PB) * 0.7 + MRP(PT) * 0.3 b) Formulario de recolección de información Para obtener el VPBRi_ro (valor de las prácticas base para el resultado i, realizadas o llevadas a cabo por la organización) y NPTRi_ro (número de productos de trabajo realizadas o llevadas a cabo por la organización), se debe tener un formulario de recolección de información por cada uno de los procesos que se desean evaluar del modelo de referencia de procesos. En la Tabla 04 se presenta el instrumento de recolección de información del proceso. El valor de la métrica VPBRi_ro (Valor de las prácticas base para el resultado i, realizadas o llevadas a cabo por la organización) determina el nivel de capacidad, el cual se obtiene a partir del instrumento de recolección de información. Cada nivel de capacidad consta de una serie de atributos, los cuales se miden de acuerdo al porcentaje de alcance: • N (No alcanzado) 0% a 15%. • P (Parcialmente Alcanzado) >15% a 50%. • L (Ampliamente Alcanzado) >50% a 85%. • F (Totalmente Alcanzado) >85% a 100%. Tabla 4.4 Instrumento de recolección de información ID del Proceso MAN.5 Grado de Realización Nombre del proceso Gestión de Riesgo Propósito del Proceso PRACTICA BASE Nunca Casi Nunca Casi Siempre Siempre SPB1 Se ha determinado el alcance de la gestión de riesgos? X SPB2 Se han definido las estrategias y medidas para tratar, analizar y monitorear el riesgo a nivel de proyecto y organizacional? X SPB3 Como se identifican los riesgos? Inicialmente y como ellas se desarrollan en el desarrollo del proyecto? X SPB4 Se analizan los riesgos? Se aplican medidas para determinar la prioridad X 44 SPB5 Se definen acciones y como debe tratarse a los riesgos? X SPB6 Se monitorea los riesgos? X SPB7 Se toma medidas preventivas y acciones correctivas para los riesgos? X A través de la combinación del instrumento y las medidas definidas anteriormente, se puede obtener un valor de la medida más objetivo del rendimiento del proceso. Para los otros casos se realizará el mismo procedimiento, por tanto solo se mostrará los resultados en la evaluación de cada proceso. 4.1.5.1 Proceso de Gestión de Riesgos La Gestión de los Riesgos del Proyecto incluye los procesos relacionados con llevar a cabo la planificación de la gestión, la identificación, el análisis, la planificación de respuesta a los riesgos, así como su seguimiento y control en un proyecto 22. El propósito de la Gestión de los Riesgos del Proyecto es aumentar la probabilidad y el impacto de eventos positivos, y disminuir la probabilidad y el impacto de eventos negativos para el proyecto 22. Se ha tomado conocimiento que en la gestión de riesgos, se pueden presentar riesgos potenciales relacionados con aspectos técnicos, costos y plazos. Por ello, la empresa X consideró importante: Identificar y evaluar los riesgos en el proyecto Z. a) Situación inicial: Para identificar los riesgos, se realizó el análisis que permitió fácilmente identificar las dificultades que se tienen en la empresa con respecto al proceso de Gestión de Riesgos. Sin embargo, la empresa cuenta con las expectativas de considerar las recomendaciones en su ciclo de vida a fin de ir mejorando en sus procesos internos. Fortalezas  Compromiso de la Alta Dirección para la realización de actividades de planificación asociado a la Gestión de Riesgos.  La organización es consciente y se encuentra preparada para realizar las mediciones y tratamiento de los riesgos. Debilidades  No se cuenta con una Estrategia de Riesgos (Plan).  Desconocimiento del personal en Seguimiento en Gestión de Riesgos. (Mediciones) 45 Resultados esperados según la norma ISO/IEC 15504-5 para el proceso de Gestión de Riesgos 32: 1. Se determina el alcance de la gestión de riesgos a ser ejecutado; 2. Se definen e implementan estrategias apropiadas de gestión de riesgos; 3. Se identifican los riesgos en la planificación de proyectos como ellos se desarrollan y durante la conducción del proyecto; 4. Se analizan los riesgos en términos de probabilidades y consecuencias y se determina la prioridad en el tratamiento de estos riesgos; 5. Se definen, aplican y evalúan las mediciones de riesgo para determinar los cambios en el estado del riesgo y el progreso de las actividades de tratamiento; 6. Se sigue el tratamiento apropiado para corregir o evitar el impacto del riesgo basados en su prioridad, probabilidad y consecuencia u otros principios de riesgo definido. Al realizar el levantamiento de información y evaluación en base a los cuestionarios elaborados en función a la ISO/IEC 15504, el que contó con apoyo del Jefe de Proyectos y 2 Analistas, se pudo observar que el nivel de capacidad de este proceso es 41% (Parcialmente Alcanzado, véase Anexo Nº 01) y esto se debe a que la empresa tiene identificado los Riesgos que generalmente se presentan en los proyectos asociados al ciclo de vida de software, los cuales se muestran en el Cuadro 4.4. Cuadro 4.1 Riesgos identificados Nº Riesgo Descripción Detallada Impacto Probabilidad a Ocurrir Estrategia de Mitigación R01 Ausencia de los usuarios en las reuniones. Alto 15% Nombrar al personal de reemplazo. Transferencia de conocimientos, información y documentos al personal sustituto. R02 Deficiencia en la comunicación con los usuarios Alto 10% Establecer un lenguaje sencillo y comprensible adecuado a la preparación de los usuarios. R03 Falta de aprobación de algún documento presentado al cliente. Alto 10% Definir en el cronograma los hitos, los cuales tienen que ver con los entregables del documento. R04 Cambio en la Solución Operativa. Alto 10% Comunicación permanente con los usuarios para anticipar posibles cambios. Reuniones periódicas de seguimiento. R05 Cambio en los requerimientos funcionales por partes de los usuarios. Alto 10% Documentar los requerimientos, validarlos, analizar el impacto (costo, tiempo, calidad, alcance) y consolidarlos mediante un acta. (Mitigación). También la empresa cuenta con una secuencia de actividades 46 asociadas a la Gestión de Riesgos; sin embargo no se ejecuta, por ser un proceso largo y no práctico. Dichas actividades se manifiestan en la Figura. Figura 4.1 Proceso de Gestión de Riesgos definido b) Propuesta de mejora: El modelo propone la documentación del proceso con respecto a la identificación, análisis, tratamiento y monitoreo continuo de los riesgos 33. Se elaboran y procesan encuestas para recoger la información asociada a la gestión de riesgos; establecimiento de los roles y responsabilidades, definiendo al líder o jefe del proyecto y considerando el presupuesto o recursos humanos ante posibles contingencias. La empresa X no cuenta con un proceso establecido para la Gestión de Riesgos; sin embargo para el desarrollo de sus anteriores proyectos consideraba como anexo al Plan de Desarrollo de Software un listado de Posibles Riesgos que podían presentarse en la ejecución de los proyectos. Para el proyecto Z Web se introdujeron las siguientes mejoras como la elaboración e introducción formal de las siguientes herramientas en la empresa: Guía para identificar Riesgos y Matriz de Riesgos (Véase Anexo Nº 04), para ello se realizó la propuesta de los siguientes formatos: 47 - Guía para identificar riesgos, de acuerdo a la experiencia del equipo se plantea una seria de preguntas a fin de identificar y clasificar los riesgos que puedan presentarse en los proyectos informáticos. - Matriz de riesgos, tomando en cuenta la experiencia del equipo. Se implementa esta matriz, en donde se deberán registrar los riesgos del proyecto, con todos los campos de impacto si fuera posible. Como parte del monitoreo de todos los proyectos se ha establecido que cada semana o al menos cada 15 días se realizarían coordinaciones, ya sea presenciales o virtuales entre los participantes del proyecto. Adicionalmente, se propuso realizar las actividades asociadas al proceso de Gestión de Riesgos 22 y se muestran a través de la siguiente figura: Figura 4.2 Estado actual del Proceso de Gestión de Riesgos El equipo ha establecido en la planificación e identificación de posibles riesgos que se detectaron en el proyecto Z Cliente/Servidor, realizar ajustes en el proyecto del Z Web como se enuncia a continuación:  Ausencia de los usuarios en las reuniones.  Deficiencia en la comunicación con los usuarios.  Falta de aprobación de algún documento presentado al cliente.  Cambio en la Solución Operativa.  Cambio en los requerimientos funcionales por partes de los usuarios.  Cambio del Usuario Líder  No se cuenta con el ambiente apropiado para llevar a cabo las pruebas.  No se determinó apropiadamente el ciclo de vida del proyecto (Cuantos días, horas de demora en la culminación de la actividad o actividades del proyecto) Durante el proyecto se presentaron situaciones de riesgo como la 48 imprevista actualización de los estándares de tecnología del cliente; sin embargo como se encuentra definido en actas la tecnología del desarrollo del proyecto, ya no se presentó mayores inconvenientes. Por el lado del equipo desarrollador se presentó la salida inesperada del desarrollador principal del proyecto; sin embargo como el análisis y diseño se encontraba documentado, se pudo continuar el desarrollo con otro desarrollador del staff de personal interesado en participar en los proyectos de la empresa X. c) Piloto: La propuesta de mejora fue aceptada e implementada mediante el piloto de construcción e implementación del Proyecto Z Web. Al finalizar el piloto los integrantes del equipo de la empresa (Jefe de Proyectos y 2 Analistas Programadores) tenían documentado lo correspondiente al proceso de Gestión de Riesgos, toda vez que los participantes del proyecto tenían conocimiento de los riesgos, así como las métricas asociadas, lo que facilitó el monitoreo y supervisión de este proceso. Los riesgos afectan a nivel de costos, satisfacción del cliente, cronograma, calidad; es por ello que la habilidad para gestionar los riesgos y prácticas basadas en la experiencia es un factor fundamental para el éxito de un proyecto. Dentro del proyecto del Z Web se acentuaron los riesgos asociados a la ausencia de usuarios, cambios en los requerimientos funcionales; situaciones que fueron superadas mediante coordinaciones, actas, y especificaciones documentadas. También se identificaron las mediciones y nivel de impacto con respecto a la Matriz de Riesgos. Al contar con el resultado exitoso de este piloto 79% (Ampliamente Alcanzado), se tomará como recomendación formal a la empresa la adopción de la metodología propuesta a fin que mantenga el nivel 1 o realizado del proceso de Gestión de Riesgos. (Ver método de evaluación 48 en el Anexo Nº 01) 4.1.5.2 Proceso de Aceptación de Software El propósito es ayudar al adquirente a que el producto cumpla con los requisitos 33. Antes de la aceptación del Software, el cliente realiza las pruebas. Son básicamente pruebas funcionales, sobre el sistema completo, y buscan una cobertura de la especificación de requisitos y del manual del usuario. Estas pruebas se realizan durante el desarrollo o cuando el producto se encuentre terminado e integrado o pudiera ser 49 una versión del producto o una iteración funcional pactada previamente con el cliente. a) Situación inicial: De la revisión realizada sobre este proceso con el equipo de la empresa X, se ha percibido el interés de conocer los procedimientos y lo necesario a fin de facilitar la obtención de los requisitos para la gestión del proceso de aceptación del producto o servicio. Fortalezas  Existen formatos para la aceptación del producto y/o servicio.  Se tiene conocimiento de los trámites administrativos para iniciar el proceso de aceptación en el Sector Público. Debilidades  No existe una estrategia de aceptación planificada ni documentada en el Sector Público.  No se sabe cómo aplicar el proceso de aceptación; empleando las sugerencias que señala la ISO/IEC 12207: 2008. Resultados esperados según la norma ISO/IEC 15504-5 para el proceso de Aceptación de Software 32: 1. El producto software entregado y / o servicio se evalúan en relación con el contrato; 2. La aceptación del cliente se basa en los criterios de aceptación acordados; 3. El producto de software y / o servicio es aceptado por el cliente. Aplicando la ISO/IEC 15504 se realizó el levantamiento de información con apoyo del Jefe de Proyectos y 2 Analistas Programadores, se pudo observar que el nivel de capacidad de este proceso es 43% (Parcialmente Alcanzado, véase Anexo Nº 02). Según la evaluación realizada, la empresa cuenta con formatos para este proceso, los cuales fueron identificados por el equipo del proyecto y son los siguientes:  Formatos de Especificaciones de Casos de Pruebas, el que permite especificar como se van a cumplir los casos de uso para el desarrollo de sistemas.  Formatos de actas de reunión y de conformidad de las revisiones/pruebas. 50  Considerar: Requisitos de Personal, Requisitos de Infraestructura de Pruebas, Requisitos de Información: Diagrama de flujo asociado al Proceso de Aceptación 18. Figura 4.3 Estado actual del Proceso de Aceptación de Software b) Propuesta de mejora: El modelo propone la documentación del proceso con respecto a las revisiones y pruebas de producto de software, y ante ello la empresa responde positivamente, cuenta con los formatos adecuados; sin embargo dicha documentación no estaba organizada. Por ello se propone las siguientes especificaciones en los estándares de Pruebas y Aceptación: Para las pruebas de aceptación: 1. En la organización existe un responsable para realizar las pruebas. 2. Se cuenta y se usa el catálogo de pruebas. 3. Se verifica que las especificaciones estén correctamente implementadas. 51 4. Se verifica que estén implementadas las funcionalidades del documento de requerimientos. 5. Los tipos de defectos u observaciones son identificados. Por el lado del cliente/usuario es necesario estar alerta o reforzar lo siguiente:  Mantener una documentación detallada de las pruebas realizadas o la aparición de nuevos requerimientos.  Conseguir la aprobación inmediata realizada por el área de informática de la entidad. Como resultado del análisis del proyecto Z cliente/servidor y tomando en cuenta la experiencia en proyectos de desarrollo de sistemas, se realiza las propuestas de mejora a considerar, a través de las siguientes plantillas o formatos: (Véase Anexo Nº 05). - Informe de Pruebas, previo a la aceptación del Software. Es relevante contar con el informe sobre el resultado de las pruebas, lo cual facilitaría la aceptación del Cliente. - Acta de Reunión. Mantener organizadas las actas de reunión con los usuarios en un directorio digitalizado permite contar con un historial de acuerdos y facilita la continuidad de los proyectos, evita situaciones de mal entendimiento. c) Piloto: Durante el proyecto del Z Web, se implementó la mejora de este proceso a través de la documentación necesaria para realizar la gestión de las Pruebas y Aceptación de Software. Ahora la empresa cuenta con buenas prácticas (se obtuvo 78% para el cumplimiento) y se recomienda formalizar la adopción de la metodología con respecto a este proceso a fin de evidenciar el nivel 1 o realizado que tiene, por ello la decisión de incluirlo en el alcance de la mejora. (Ver método de evaluación en el Anexo Nº 02). Al finalizar el piloto los integrantes del equipo de la empresa (Jefe de Proyectos y 2 Analistas Programadores) tenían documentado lo correspondiente al proceso de Aceptación de Software y se evidenció que la empresa se encuentra preparada; por tanto se sintieron satisfechos, toda vez que ellos tienen experiencia en diversos proyectos informáticos o de desarrollo de sistemas. 52 Como parte de las lecciones aprendidas, para desarrollar el Plan de Pruebas y Pruebas de Aceptación, se ha identificado que debe complementarse dicha documentación toda vez que se tiene con una base de datos de pruebas con instancias de pruebas generadas, que correspondan a la casuística de pruebas que el cliente defina, distribución de responsabilidades en las pruebas, donde se especifica las funciones y responsabilidad de los participantes en el proceso de pruebas, estrategia del Plan de Pruebas (pruebas unitarias, pruebas integrales), control y monitoreo de las pruebas realizadas a fin de llegar al producto/servicio esperado. Al finalizar la verificación de cada uno de los casos de prueba se firma un acta. 4.1.5.3 Proceso de Gestión de Activos de Reuso La Gestión de Activos de Reuso incluye la planificación, administración y control del programa de reutilización. Es relevante aprovechar sistemáticamente las oportunidades de reutilización y para ello es conveniente contar con un repositorio almacenamiento y recuperación de activos, dichos activos deben ser almacenados basados en criterios adecuados, hacerles seguimiento en cuanto a modificaciones y cuando se reporta problemas en los usuarios de reuso. a) Situación inicial: El análisis permitió identificar los inconvenientes que se tienen en la Empresa con respecto al proceso de Gestión de Activos de Reuso. Sin embargo, la empresa X cuenta con las expectativas de considerar las recomendaciones en su ciclo de vida a fin de ir mejorando en sus procesos internos, toda vez que la mayoría de soluciones no son almacenadas de una forma adecuada, toda vez que cuando se reutiliza componentes se insume tiempo innecesario solo en ubicarlos. Fortalezas  Existe control de versiones de los objetos reusados en el directorio del equipo de trabajo.  Éxito en el reúso de objetos para el desarrollo de aplicaciones en Power Builder. Debilidades  No existe una estrategia documentada.  No se encuentran clasificados ni documentados los modelos. Resultados esperados según la norma ISO/IEC 15504-5 para el proceso de Gestión de Activos de Reuso 32: 53 1. Se definen las estrategias de reuso de la organización incluyendo su propósito, alcance, metas y objetivos; 2. Se identifican los dominios para las potenciales oportunidades de reuso; 3. Se evalúa la capacidad de reuso sistemático en la organización 4. Se evalúa el reuso potencial en cada dominio; 5. Se evalúa las propuestas de reuso para asegurar que el reuso del producto es adecuado para la aplicación propuesta; 6. Se implementa la estrategia de reuso en la organización; 7. Se establece mecanismos de retroalimentación, comunicación y notificación que son usados entre las partes afectadas; 8. Se monitorea y evalúa el programa de reuso. Antes de implementar las mejoras la Empresa no contaba con una secuencia de actividades asociadas a este proceso; sin embargo, aplicando la ISO/IEC 15504 se realizó el levantamiento de información con apoyo del Jefe de Proyectos y 2 Analistas Programadores y se pudo observar que el nivel de capacidad de este proceso es 17% (Parcialmente Alcanzado, véase Anexo Nº 03). b) Propuesta de mejora: Según la evaluación realizada la Empresa no alcanzaba el nivel realizado, y tras analizar el proyecto Z cliente/servidor se ha visto por conveniente reforzar este proceso a través de la definición de las estrategias de reuso de la organización y la reutilización de un conjunto de herramientas (componentes de código, diseño de las especificaciones). Se tiene que apostar por el liderazgo administrativo y soporte. Cada organización implementa sus estrategias y métodos de reuso, para la empresa X se propone considerar un activo de reuso como válido:  Permita subir, descargar, actualizar sus versiones.  Permita el control de acceso mediante asignación de permisos.  Considere documentación asociada.  Especifique al creador o creadores del activo.  Especifique si el componente depende de otro componente. 54  Especifique la versión del activo.  Utilice el estándar de presentación de documentos vigente. Para la organización de los activos se plantea utilizar como herramienta de apoyo un sistema de control de versiones libre, cuyo repositorio permitirá gestionar componentes de código, mantener la trazabilidad entre los niveles de artefactos (por ejemplo, código de diseño, el diseño de las especificaciones), catalogar los objetos del repositorio que proporciona las descripciones de los componentes para ser reutilizados, documentar el conocimiento de los procesos de negocio de los proyectos realizados y posibles activos para la reutilización 13 como las lecciones aprendidas 34, listas de verificación, plantillas de proyecto de gestión y estándares de desarrollo de software. Con el uso de lo planteado se espera incrementar la productividad en el desarrollo de aplicaciones. La implementación permitirá gestionar los activos, referenciar las plantillas o formatos. Abreviaciones de los documentos y formatos/plantillas: 1) Plan de Desarrollo del Sistema (PDS) 2) Requerimientos (REQ) 3) Arquitectura (ARQ) 4) Plan de Pruebas (PPS) 5) Informe de Pruebas (IPS) 6) Manual de Usuario (MUS) 7) Manual de Instalación(MIS) 8) Acta de Conformidad(ACT) Diagrama de flujo asociado al Proceso de Gestión de Reuso 4 Figura 4.4 Estado actual del Proceso de Gestión de Reuso 55 La catalogación de recursos seguirá la siguiente estructura:  Estándares y plantillas de desarrollo de software en la carpeta DOCUMENTACION  Fuentes de aplicativos informáticos en la carpeta FUENTES  Instaladores de programas para desarrollo, base de datos y otros en la carpeta INSTALADORES El acceso a los recursos se realizará usando las herramientas propias de Subversión y que se detalla a continuación:  Servidor Repositorio Subversión (SVN)  Interface de administración de Servidor: Visual SVN  Cliente de conexión al Servidor SVN: Tortoise SVN Servidor Repositorio Subversión, es un servidor repositorio que sirve para almacenar las versiones y la historia de proyectos de software. Permite que varias personas puedan trabajar en un mismo proyecto de software de manera colaborativa, de forma centralizada y sin afectar el trabajo que cada uno realiza. Básicamente, como repositorio que es, permite también almacenar un histórico de revisiones y recuperar una versión anterior de código, parcial o totalmente. Se instala en un servidor. La interface Visual SVN permite la instalación del SVN y su administración. Además, la creación de los Repositorios y carpetas, usuarios y tipos de acceso a estas carpetas. Se instala en un servidor. El cliente Tortoise SVN, permite la interacción con el Servidor haciendo posible la actualización bidireccional de las aplicaciones entre el Repositorio y la copia de trabajo local. Bidireccional porque se puede descargar del Servidor una copia local y actualizar una nueva copia al Repositorio. Se instala en las máquinas cliente. c) Piloto: La propuesta de mejora fue aceptada e implementada mediante el piloto de construcción e implementación del Proyecto Z Web. Para que este proceso funcione se realizó la definición de las estrategias de reuso de la organización y la implementación de un repositorio entre grupos. Es decir, realizar la gestión de activos (código java, formatos para las diferentes etapas, en general activos reutilizables) y aplicar los procedimientos necesarios con el propósito de almacenar, identificar, clasificar, rastrear las modificaciones y 56 versiones del activo. El analista programador de mayor experiencia es el encargado de la gestión de los activos. Para la gestión de activos se utilizaron las herramientas libres Subversion SVN y CVS Tortoise, las que permiten administrar librerías, aplicaciones y documentación, realizar el seguimiento de control de versiones, facilitando al equipo de desarrollo del Proyecto Z Web mediante lo siguiente:  Aplicaciones y utilidades reutilizables  Componentes de tecnología reutilizables  Componentes de aplicación  Componentes de modelo de negocio  Arquitectura/diseño, artefactos  Test datos/test scripts  Estándares, lineamientos, plantillas, mejores prácticas Para la identificación y clasificación de los activos, se realizaron revisiones durante el piloto, así como seguimiento de la cantidad de veces que se ha utilizado los diferentes activos. Finalmente se analiza las ventajas de uso de estos activos y se realizan mejoras de los activos con el objetivo de hacerlos fáciles de usar. Al finalizar el piloto los integrantes del equipo de la empresa (Jefe de Proyectos y 2 Analistas Programadores) comprendieron la importancia y utilidad de un gestor de reúso (componentes de código, artefactos, fichas del proceso de negocios, versiones del aplicativo del Z Web con su respectiva gestión de cambios), toda vez que facilita la búsqueda, la accesibilidad y evita la posible redundancia en los proyectos informáticos. Se recomienda formalizar la adopción de este proceso, toda vez que las prácticas y resultados alcanzan un cumplimiento de 52% que es el nivel de capacidad Ampliamente Alcanzado. Ver método de evaluación en el Anexo Nº 03. 57 Capítulo 5 Conclusiones y Recomendaciones El presente capítulo presenta las conclusiones y recomendaciones finales a través del proyecto del ciclo de mejora. 5.1 Conclusiones El trabajo realizado estuvo dirigido a cumplir con los siguientes objetivos: • Realizar el diagnóstico de los procesos según el ciclo de vida de desarrollo de software. • Elaborar propuestas de mejora de procesos según las mejoras prácticas. • Implementar el piloto con las propuestas de mejora y realizar las evaluaciones correspondientes. La forma en cómo se alcanzaron los objetivos se describe a continuación, explicando en mayor detalle cómo se implementó las mejoras en el piloto Web del proyecto. Se realizó un ciclo de mejora aplicando la ISO/IEC 12207:2008 como marco de referencia para la mejora de procesos. La selección de los procesos y priorización, se realizó teniendo en cuenta los métodos y herramientas empleadas por COMPETISOFT como las entrevistas, cuestionarios, que permitieron la recopilación, depuración y análisis de la información, con el objetivo de producir información que sirva de insumo para las matrices de selección y priorización: objetivos vs. problemas, objetivos vs. procesos, problemas vs. procesos; que emplea la técnica de grupo nominal, para proporcionarle un peso a los ítems de las diferentes matrices. Se determinó la necesidad de mejorar los 3 procesos priorizados tomando en cuenta las sugerencias de la gerencia. La evaluación de los procesos, se obtuvo en base a los cuestionarios que fueron elaborados tomando como referencia la norma ISO/IEC 15504:5, la cual plantea que se debe cumplir un conjunto de resultados, prácticas base y productos de trabajo para cada nivel que se quiere alcanzar. Es así que para elaborar el perfil de capacidades, se tomó los cuestionarios en los dos proyectos: Cliente/Servidor y Web, los cuales se indican en el anexo 1-2-3. Las propuestas de mejora fueron resultado de la observación entre lo que se tiene y lo que falta por alcanzar según el nivel objetivo que señala la norma; contando además con la experiencia del asesor, 58 tesista, así como la gerencia de la empresa para obtener la lista de mejoras. Lo que falta por alcanzar según la norma lo conforman las prácticas base y los productos. La ejecución de las mejoras en el proyecto contó con el apoyo de la gerencia, que fue llevada de manera gradual con el objetivo de ir creando conciencia en las personas que cambiando de a pocos en lo que se realiza, se llegará a que la empresa sea mejor y logre un bienestar a nivel general. Se propuso cambios considerando respuesta inmediata, con el fin que todo el equipo sienta que está en buen camino. Los procesos a ser mejorados en la empresa fueron: Gestión de Riesgos, Gestión de Aceptación de Software y Gestión de Activos de Reuso, los cuales obtuvieron el nivel realizado. Para el caso de Riesgos se elaboraron plantillas o formatos que facilitaron la identificación de los riesgos que pueden presentarse en los proyectos y la matriz de riesgos para el seguimiento y considerar las acciones para combatirlos o evitarlos. Para el caso de Aceptación de Software, lo positivo es que la empresa contaba inicialmente con documentación; sin embargo la mejora a través de la elaboración del Plan de Pruebas permitió integrar varios contenidos asociados que estaban dispersos y servirían para formalizar las pruebas a realizarse en los proyectos de desarrollo de sistemas. Para el caso de Activos de Reuso se planteó la reutilización de los componentes de código, diseño de las especificaciones, repositorio de reutilización para el desarrollo de sistemas a través del uso de herramientas Subversion y de control de versiones libres, limitadas en opciones pero suficientes para la pyme. 5.2 Recomendaciones Para el próximo ciclo de mejora se recomienda revisar el proceso de Aseguramiento de la Calidad de Software; sin embargo la empresa no lo consideró porque priorizó en los otros 3 planteados en el proyecto (Gestión de Riesgos, Gestión de Aceptación de Software y Gestión de Activos de Reuso), toda vez que los consideraba críticos. Se recomienda que la empresa siga aplicando pilotos hasta obtener la experiencia y habilidad necesaria para que la metodología empleada sea utilizada en cualquier tipo de proyecto. La mype debería designar una persona de la organización que tenga como responsabilidad la implementación de las mejoras de procesos, de modo que se consolide la participación de la empresa en los procesos de mejora e involucre más a las partes operativas a fin de 59 apoyar al logro de las metas establecidas. Es necesario que la empresa designe recursos (tiempo, personal) para la ejecución del próximo ciclo de mejora. Es vital se establezca como parte de las actividades del personal aquellas referidas a la mejora de procesos, así como planificar capacitaciones en identificación efectiva de riesgos, definición de plan de mitigación y contingencia de riesgos, actualización en métodos ágiles, gestión de proyectos. Todo el personal de la empresa debe entender que el objetivo de usar modelos de calidad de procesos, conllevará a una mejora en todas las áreas y niveles de la empresa; lo que se puede lograr comprometiendo inicialmente a la gerencia general con su apoyo y participación, y esta a su vez al resto de la organización. La empresa evidenciará mejora en la reducción costos, mejora de procesos y aumento de la calidad del producto final. 60 Cuestionario N° 01 – Ficha recolección de datos de la empresa 1. Datos generales de la empresa  Razón social:  Registro Único del Contribuyente (RUC):  Fecha de inicio de operaciones:  Dirección:  Teléfonos:  Página WEB: 2. Guía para analizar el Plan Estratégico  Misión:  Visión:  Análisis FODA: Para ello, se deberá tomar en cuenta: o Condiciones de su entorno-mercado o Los puntos fuertes, débiles y limitaciones, tanto propias como del entorno mercado o Las fuerzas de los competidores o Sus planes sobre futuras acciones  Objetivo estratégico Propósitos muy específicos a donde se debe llegar (grandes finalidades de la Organización)  Objetivos Específicos Es el siguiente nivel que se obtiene al disgregar los objetivos estratégicos  Estrategia A partir del diagnóstico de la empresa, su entorno y su posición relativa, el siguiente paso consiste en planear hacia dónde queremos ir y cómo lograrlo. 3. Tipos de proyectos que ejecuta (Indicar con una “X”)  Desarrollo y adecuaciones de software a) Implementación de sistemas de información a la medida: b) Personalización o adecuaciones de software: c) Integración de sistemas: d) Mantenimiento y soporte de sistemas de software:  Consultoría a) Análisis y diseño de sistemas de información: b) Diseño y mejoramiento de procesos c) Consultoría en TI: d) Inteligencia de Negocios: e) Capacitación y asistencia técnica: 61 f) Otro: Información obtenida del personal de la empresa 1. Cuáles son los objetivos de la empresa: 2. Cuáles son los problemas de la empresa: 3. Cuáles son los procesos de la empresa: Cuadro 4.1: Objetivos de Negocio vs. Problemas de Negocio 1 2 3 4 5 6 Pocas utilidades o bajos ingresos para la empresa Personal no tiene 100% disponible de su tiempo Cambios en la organizaci ón y procesos operativos del Estado No hay posiciona miento de la empresa Demora por parte del cliente en las diferentes etapas del proyecto Mala administra ción del conocimie nto de la organizaci ón Mejorar el flujo y rentabilidad de la empresa 8 16.00% 2 1 2 2 2 2 Entregar productos y/o servicios de calidad 7 14.00% 2 2 2 1 1 1 Minimizar el tiempo en desarrollo 6 12.00% 1 2 2 1 2 2 Generar confianza y fidelizacion de clientes 8 16.00% 1 2 1 2 1 1 Ampliar el desarrollo de productos y/o servicios al sector privado 7 14.00% 2 1 1 2 1 2 Generar alianzas con socios estrategicos 6 12.00% 1 1 1 2 1 1 Mantener un staff de profesionales altamente capacitados en las ultimas tecnologias 8 16.00% 1 2 1 1 1 2 50 1.44 1.58 1.42 1.58 1.28 1.58 Problemas Peso %Peso Objetivos 62 Cuadro 4.2: Objetivos de Negocio vs. Procesos ISO/IEC 12207:2008 63 64 Cuadro 4.3: Problemas de Negocio vs. Procesos ISO/IEC 12207:2008 65 66 Cuestionario N° 02 – Gestión de Riesgos 1. ¿Se ha determinado el alcance de la gestión de riesgos? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 2. ¿Se han definido las estrategias y medidas para tratar, analizar y monitorear el riesgo a nivel de proyecto y organizacional? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 3. ¿Cómo se identifican los riesgos? Inicialmente y cómo ellas se desarrollan en el desarrollo del proyecto? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 4. ¿Se analizan los riesgos? Se aplican medidas para determinar la prioridad? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 5. ¿Se definen acciones y como debe tratarse a los riesgos? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 6. ¿Se monitorean los riesgos? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 7. ¿Se toma medidas preventivas y acciones correctivas para los riesgos? a) Nunca 67 b) Casi nunca c) Casi siempre d) Siempre Cuestionario N° 03 – Apoyo de Aceptación de Software 8. ¿Se ha evaluado el producto entregado al cliente a través de los criterios de aceptación? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 9. ¿Han existido cumplimiento en los acuerdos? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 10. ¿Qué tan frecuente se ha realizado la aceptación del producto? a) Nunca b) Casi nunca c) Casi siempre d) Siempre Cuestionario N° 04 – Gestión de Activos de Reuso 11. ¿ Se ha definido la estrategia de reutilización de organización? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 12. ¿ Se puede identificar áreas para un reuso potencial? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 13. ¿ Se puede evaluar la capacidad de reutilizar? a) Nunca b) Casi nunca 68 c) Casi siempre d) Siempre 14. ¿ Se evalúan dominios para un reuso potencial? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 15. ¿ Se evalúan las propuestas de reutilización? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 16. ¿ Se implementa el programa de reutilización? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 17. ¿ Se recoge y gestiona el aprendizaje de reuso? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 18. ¿ Se obtiene retroalimentación de reutilización? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 19. ¿ Se supervisa la reutilización? a) Nunca b) Casi nunca c) Casi siempre d) Siempre 69 Anexo Nº 01 Resultados del Proceso de Gestión de Riesgos: Primera Evaluación: 70 Segunda Evaluación, luego de la mejora realizada (5 meses después) 71 Anexo Nº 02 Resultados del Proceso de Aceptación: Primera Evaluación (solo se realizó una evaluación toda vez que se observó que cumplían el nivel 1) Proposito del Proceso Nunca Casi Nunca Casi Siempre Siempre X X X Evaluar el producto entregado a través de los criterios de aceptación Cumplimiento de acuerdo Grado de Realización Aceptación del producto producto PRACTICA BASE EN FUNCION DE LAS PRACTICAS BASE NRP_std = Numero de Resultados de Proceso 3 NPB_std = Numero de Practicas Base 3 PRP = Peso de cada uno de los resultados en el total, es 1 entre el numero de resultados = "1/3" 0.33 1 2 3 NPBRi_std = Nro de Practicas Base para el logro de un resultado 1 2 1 VPBRi_ro = Valor de las practicas para el resultado , llevadas acabo por la organización, se obtiene del cuestionario,sumadas 0.3 0.6 0.6 GCRi(PB) = Grado de Cumplimiento en funcion de las practicas base = VPBRi_ro/NPBRi_std 0.3 0.3 0.6 MRP(PB) = Suma de todos los GCRi(PB)*PRP El resultado varia entre uno y cero 0.4 EN FUNCION DE LOS PRODUCTOS DE TRABAJO NPTE_std = Numero de productos de trabajo de entrada 7 NPTS_std = Numero de productos de trabajo de salida 3 1 2 3 NPTERi_std = Nro de Productos de entrada para el resultado 5 3 1 NPTSRi_std = Numero de productos de trabajo de salida para el resultado 1 1 1 NTPTRi = Numero total de productos de trabajo para el resultado 6 4 2 NPTRi_ro = Nro de productos de trabajo para el resultado llevadas a cabo por la organización. 3 2 1 GCRi (PT) = Grado de Cumplimiento en funcion de los productos de trabajo = NPTRi_ro / NTPTRi 0.5 0.5 0.5 MRP(PT) = Suma de todos los GCRi (PT)*PRP El resultado varia entre uno y cero 0.5 MRP = MRP(PB) * 0.7 + MRP(PT) * 0.3 43% Resultado Resultado 72 Segunda Evaluación, luego de la mejora realizada (5 meses después) Proposito del Proceso Nunca Casi Nunca Casi Siempre Siempre X X X Evaluar el producto entregado a través de los criterios de aceptación Cumplimiento de acuerdo Aceptación del producto producto Grado de Realización PRACTICA BASE EN FUNCION DE LAS PRACTICAS BASE NRP_std = Numero de Resultados de Proceso 3 NPB_std = Numero de Practicas Base 3 PRP = Peso de cada uno de los resultados en el total, es 1 entre el numero de resultados = "1/3" 0.33 1 2 3 NPBRi_std = Nro de Practicas Base para el logro de un resultado 1 2 1 VPBRi_ro = Valor de las practicas para el resultado , llevadas acabo por la organización, se obtiene del cuestionario,sumadas 1 1.6 0.6 GCRi(PB) = Grado de Cumplimiento en funcion de las practicas base = VPBRi_ro/NPBRi_std 1 0.8 0.6 MRP(PB) = Suma de todos los GCRi(PB)*PRP El resultado varia entre uno y cero 0.8 EN FUNCION DE LOS PRODUCTOS DE TRABAJO NPTE_std = Numero de productos de trabajo de entrada 7 NPTS_std = Numero de productos de trabajo de salida 3 1 2 3 NPTERi_std = Nro de Productos de entrada para el resultado 5 3 1 NPTSRi_std = Numero de productos de trabajo de salida para el resultado 1 1 1 NTPTRi = Numero total de productos de trabajo para el resultado 6 4 2 NPTRi_ro = Nro de productos de trabajo para el resultado llevadas a cabo por la organización. 4 2 2 GCRi (PT) = Grado de Cumplimiento en funcion de los productos de trabajo = NPTRi_ro / NTPTRi 0.7 0.5 1 MRP(PT) = Suma de todos los GCRi (PT)*PRP El resultado varia entre uno y cero 0.7 MRP = MRP(PB) * 0.7 + MRP(PT) * 0.3 78% Resultado Resultado 73 Anexo Nº 03 Resultados del Proceso de Reuso: Primera Evaluación: 74 Segunda Evaluación, luego de la mejora realizada (5 meses después) 75 Anexo Nº 04 Herramientas y artefactos asociados al Proceso de Gestión de Riesgos Guía para identificar Riesgos Ingeniería del Producto Requerimientos Variación de los requerimientos  Es posible que a lo largo del proyecto se quieran incorporar nuevas necesidades del negocio?  Es posible que se presenten cambios en procesos, normativa, estándares, tomas de decisiones, tecnología durante el desarrollo del proyecto?  Cambios de Personas y replanteamientos de enfoque de la solución. Completitud de los requerimientos  Fue suficiente el tiempo que se dedicó a la preparación de la definición del proyecto?  Fue adecuado el número de personas que revisaron los requerimientos ?  Los requerimientos han sido aprobados por la persona del nivel que corresponde?  Fue suficiente el número de especialidades (comercial, operaciones, tecnología, etc.) que participaron en la definición. Factibilidad de los requerimientos  Se han realizado aplicaciones similares? En cuanto a: - Tecnología, Procesos, Productos, etc.?  Nuestro personal tiene la especialización necesaria para llevar a cabo esta solución? Diseño Funcionalidad Se han identificado principales factores de calidad? extensibilidad, reusabilidad, compatibilidad, eficiencia, portabilidad, facilidad de uso, funcionalidad? modularidad Verificabilidad  Se ha involucrado el usuario en las definiciones de diseño?  Las personas que realizan la revisión son las adecuadas?  Se cuenta con la aprobación del usuario ? Codificación y Pruebas Unitarias Pruebas  Son fácilmente identificables las pruebas unitarias a realizar?  Se cuenta con casos de prueba?  Contamos con todos elementos de prueba (Datos, ambientes, etc.) Ambiente de Desarrollo Capacidad Se cuenta con una adecuada disponibilidad de Hardware (Disco, Base Datos, etc.) para garantizar un adecuado nivel de pruebas a lo largo de todos los ambientes? 76 Fiabilidad El software base sobre el cual se desarrolla el aplicativo ha sido antes utilizado? Se encuentra ya instalado y operativo? O debemos considerar tiempos adicionales de definición e instalación? Conocemos la operatividad del software base que será utilizado? Gestión del Proyecto Recursos Recurso Humano  Habrá continuidad de los recursos? (manejo de vacaciones, múltiples proyectos simultáneos)  Se requiere alguna especialización de los recursos?  Tenemos dependencia de algún recurso especializado? Presupuesto  La estimación de presupuesto se realizó en base a estándares conocidos?  El número de recursos estimados fue el adecuado?  Existe algún entregable, luego del cual conoceremos más precisamente los costos? Facilidades / Logística  La asignación de recursos está garantizada para el momento en que son requeridos?  Se dispondrá del presupuesto en el momento que se requiera reaizar el desembolso? Contratos Tipo de contrato  Cuántos contratos se manejarán dentro del proyecto? De qué tipos son estos contratos?  Corresponden a tipos de contrato pre-definidos en los que ya se tenga experiencia? Restricciones Existe alguna restricción importante de gestión, de recursos, de alcance? Ambiente de Trabajo Colaboración y clima de trabajo  ¿Existe una perspectiva positiva o negativa de los involucrados del proyecto respecto de la implementación del software?  Se cuenta con la participación y apoyo de todas las áreas involucradas?  Se han definido la forma de participación y el tiempo de dedicación de todos los involucrados?  ¿Existe una perspectiva positiva o negativa de los integrantes del equipo de trabajo respecto de su participación en el proyecto? Gestión del Proyecto Planificación  Se consideran sensatos los tiempos estimados de duración del proyecto?  Existen múltiples compromisos que escapan al alcance del manejo del gerente de proyecto? 77 Organización del Proyecto  Se encuentran claramente definidos los roles de cada involucrado en el proyecto?. Los roles y niveles definidos son los adecuados?  Existen retrasos potenciales por falta dedicación al cumplimiento de cada rol? (demora en revisión de entregables, en firma de documentos?, etc.)  Existen dificultades en participación y cumplimiento en reuniones de algún rol del proyecto? Experiencia en Adm. de proyectos Tenemos experiencia en el tipo de proyecto que se nos asigna? (de acuerdo a la tecnología, al tipo de contrato, al área de aplicación funcional, a la metodología, etc.?) MATRIZ DE RIESGOS (*) Proyecto XX-9999 - Nombre del Proyecto Item Descripción del Riesgo Probabilidad Impacto Severidad (Prob x Impacto) Fecha planificada de la revisión Fecha de revisión Responsa ble de seguimien to y atención Mitigación del riesgo Plan de contingencia Observaciones / acciones tomadas Anexo Nº 05 Herramientas y artefactos asociados al Proceso de Aceptación PLANTILLA A UTILIZAR COMO INFORME DE PRUEBAS {NOMBRE SISTEMA} {Versión n.n.n} Actualizado a {Nombre mes} {Año} 80 Historial de Revisiones Ítem Fecha Versión Equipo Autor Descripción Responsable de revisión y/o aprobación {01} {dd/mm/aaa a} {n.n.n} {Nombre del equipo} {Nombre del autor} {Descripción de los cambios en el documento} {Nombre de responsable de revisión y/o aprobación} 81 INTRODUCCIÓN [La introducción brinda una vista rápida de todo el documento respecto al sistema en desarrollo. Da una idea general del contenido del documento así como algunos alcances generales. ] OBJETIVO [Indicar el objetivo del documento.] ALCANCE [Una breve descripción del alcance de este documento y qué otros documentos se ven afectados por éste. Además debe mencionarse qué otro(s) sistema(s) están asociados o se ven afectados por el sistema en desarrollo.] DEFINICIONES Y ABREVIACIONES [Esta sección brinda la definición de aquellos términos y abreviaciones requeridas para interpretar adecuadamente el contenido de este documento. Esta información debería ser provista en un glosario del documento y aquí únicamente hacer referencia a dicho documento.] PRUEBAS EJECUTADAS {Detalle de las pruebas realizadas, detallando las ocurrencias de cada sesión} 82 PERSONAL ASIGNADO Nro. Caso de Prueba Rol Usuario asignado 1. [Caso de Prueba 1: CUS Login] [• Rol 1.] [• Usuario 1. • Usuario 2.] 2 [Caso de Prueba 2: CUS Registro de formato A] [• Rol 2.] [• Usuario 3.] RESULTADO DE LAS PRUEBAS Tipo de prueba Fecha de prueba Estado Observaciones {Tipo de pruebas a realizar} {Fecha en que se realizo la prueba} {Si se ejecuto o se encuentra pendiente o fue cancelada} {Comentarios u observaciones relevantes} {Tipo de pruebas a realizar} {Fecha en que se realizo la prueba} {Si se ejecuto o se encuentra pendiente o fue cancelada} {Comentarios u observaciones relevantes} PRUEBAS CON OBSERVACIONES PENDIENTES Tipo de prueba Observaciones Nueva fecha de prueba Usuario {Tipo de pruebas a realizar} {observación ocurrida durante la prueba} {Fecha en que se realizara la prueba} {Nombre del usuario experto} {Tipo de pruebas a realizar} {observación ocurrida durante la prueba} {Fecha en que se realizara la prueba} {Nombre del usuario experto} 83 Acta de Reunión Fecha Hora Inicio Planeada Real Duración Planeada Real Local Objetivo ASISTENTES Equipo de la empresa X Usuario - Cliente Nombre Participante Asistió Nombre Participante Asistió Agenda Revisado 1. 2. Desarrollo 1. 2. 3. Conclusiones y Acuerdos 1. 2. 3. Firmantes: 84 REFERENCIAS 1 ISO, 'International Organization for Standardization) Consulta: 23 de noviembre de 2012.< http://www.iso.org/iso/home.html>. 2 Marcos Sotelo B., 'Gestión De Tecnologías De Información '2008) Consulta: 13 de diciembre de 2013. 3 Fredy Bentancurt, 'Presentación Del Relais Internacional: Dinamizando El Mercado De Software En América Latina Y El Caribe) Consulta: 13 de diciembre de 2013. 4 S. Berzisa, and J. Grabis, 'Evaluation of Similarity and Reuse of Project Management Processes', Scientific Journal of Riga Technical University. Computer Sciences, 45 (2011), 59- 65. 5 Ruben Caballero, 'Centro De Innovación Tecnológica Del Software' Consulta: 23 de noviembre de 2012. 6 Yaimí Trujillo Casañola, 'Apuntes Sobre Modelo Ideal', Serie Científica, 3 (2010). 7 ComexPeru, 'Conocimiento Peruano Para El Mercado Mundial'2013) Consulta: 23 de enero de 2014. 8 International Electrotechnical Commission, 'About the IEC'2013) Consulta: 24 de enero de 2014. 9 Proyecto COMPETISOFT, 'Competisoft-Mejora De Procesos Para Fomentar La Competitividad De La Pequeña Y Mediana Industria Del Software De Iberoamérica. Versión 1.0', (Diciembre, 2008). 11 Mary Beth Chrissis, Mike Konrad, and Sandy Shrum, 'Cmmi Guía Para La Integración De Procesos Y La Mejora De Productos', (2009). 12 A. Davila, C. Basurto, L. Flores, R. Arisaca, R. Manrique, Sa, x, J. nchez, Pesso de Paula, and M. S. a, 'The Peruvian Component of Competisoft Project: Lesson Learned from Academic Perspective', in Informatica (CLEI), 2012 XXXVIII Conferencia Latinoamericana En (2012), pp. 1-7. 13 R.A. De Paez, 'Un Acercamiento a La Reutilización En Ingeniería De Software', EAFIT Magazine (1999), 45-63. 14 Alfredo Taboada Escajadillo, 'Industria Peruana De Software: Perspectivas - Pacis'2008) Consulta: 08 de diciembre de 2012. 15 Real Academia Española, 'Diccionario De La Lengua Española) Consulta: 10 de diciembre de 2013. 16 Marcelo G Estayno, Gladys N Dapozo, Liliana Raquel Cuenca Pletsch, and Cristina L Greiner, 'Modelos Y Métricas Para Evaluar Calidad De Software', in XI Workshop de Investigadores en Ciencias de la Computación (2009). 17 Christophe Guibert, 'Cmmi for Development 1.3'2013) Consulta: 10 de marzo de 2014 . 18 Oscar Hernando Guzmán Cortés, 'Aplicación Práctica Del Diseño De Pruebas De Software a Nivel De Programación', (2006). 85 19 INDECOPI, 'NTP-RT-ISO/IEC TR 29110-5-1-2:2012 Ingenieria De Software. Perfiles Del Ciclo De Vida Para Las Pequeñas Organizaciones', 5 (2012). 20 INDECOPI, 'NTP-RT-ISO/IEC 12207:2006 Tecnología De La Información. Procesos Del Ciclo De Vida Del Software', 2 (2006). 21 CMMI Institute, 'Published Appraisal Results'2014) . 22 Project Management Institute, 'Guía De Los Fundamentos Para La Dirección De Proyectos (Guía Del Pmbok)', 4ta Edición (2008). 23 Software Engineering Institute, 'CMMI for Development, Version 1.3', (2010). 24 ISO, 'Iso 9000 - Quality Management) Consulta: 10 de diciembre de 2013 . 25 'ISO/IEC 15504'2011) Consulta: 27 de noviembre de 2013. 26 'ISO/IEC 29110-4-1:2011', Software engineering - Lifecycle profiles for Very Small Entities (VSEs), Part 4-1: Profile specifications: Generic profile group (2013). 27 iso.org, 'Benefits of International Standards) Consulta: 08 de diciembre de 2013 . 28 'ISO/IEC, '15504-1:2004', Information technology -- Process assessment, Part 1: Concepts and vocabulary (2013). 29 'ISO/IEC, '15504-2:2003', Information technology -- Process assessment, Part 2: Performing an assessment (2013). 30 'ISO/IEC, '15504-3:2004', Information technology -- Process assessment, Part 3: Guidance on performing an assessment (2013). 31 'ISO/IEC, '15504-4:2004', Information technology -- Process assessment, Part 4: Guidance on use for process improvement and process capability determination (2013). 32 'ISO/IEC, '15504-5:2012', Information Technology — Process Assessment, Part 5: An exemplar software life cycle process assessment model (2014). 33 ———, 'International Standard Iso/Iec 12207 Software Life Cycle Processes', Software Process: Improvement and Practice, 2 (2008). 34 D. Kane, and D. Dikel, 'Managing Change to Reusable Software', in Pattern Languages of Programs (PloP) Conference (1997). 35 PACIS Ibero América Lima-Perú, 'Proyecto De Cooperación Contribución Al Crecimiento, Progreso Y Fomento En Las Nuevas Tecnologías De La Información-Region Callao) Consulta: 29 de noviembre de 2013 . 36 Gonzalo Sanchez, 'Mejora Del Proceso Software De Una Pequeña Empresa Desarrolladora De Software: Caso Competisoft-Perú Tau', (2008). 37 Toni Martin, 'Certificaciones Y Normativas De Calidad En Software'2010) Consulta: 15 de octubre de 2013. 38 Bob McFeeley, 'Ideal: A User's Guide for Software Process Improvement', (DTIC Document, 1996). 39 Ángel Méndez, 'Mejora Del Proceso Software De Una Pequeña Empresa Desarrolladora De Software: Caso Competisoft-Perú-Lim. Omega, Primer Ciclo', (2012). 40 Escuela Virtual del Mercosur, '70% De Las Mipymes Que Utilizan Software De Calidad Bajaron Costos Y Aumentaron Sus Ventas Entre Un 5% Y 25%'2013) Consulta: 13 de diciembre de 2013. 42 H. Oktaba, C.A. Esquivel, and A.S. Ramos, 'Modelo De Procesos Para La Industria De Software, Moprosoft. Versión 1.3', Colores del Modelo de Procesos de Software. http://www. 86 software. net. mx/desarrolladores/prosoft/temas_interes/moprosoft. htm (2005) Consulta: 17 de noviembre de 2012. 43 Hanna Oktaba, 'Presentación De Mejora De Procesos Para Fomentar La Competitividad De La Pequeña Y Mediana Industria Del Software De Iberoamérica'2008) Consulta: 13 de diciembre de 2013. 44 Hanna Oktaba, C Alquicira, A Su Ramos, J Palacios, C Pérez, and F López, 'Método De Evaluación De Procesos Para La Industria Del Software Evalprosoft', (Versión, 2004). 45 CÉSAR PARDO, JULIO ARIEL HURTADO, and CÉSAR A COLLAZOS, 'Mejora De Procesos De Software Ágil Con Agile-Spi Process', Dyna, 77 (2010), 263. 46 F Pino, Félix García, and Mario Piattini, 'Revisión Sistemática De Mejora De Procesos Software En Micro, Pequeñas Y Medianas Empresas', Revista Española de Innovación, Calidad e Ingeniería del Software, 2 (2006), 6-23. 47 F. Pino, F. García, F. Ruiz, and M. Piattini, 'Adaptación De Las Normas Iso/Iec 12207: 2002 E Iso/Iec 15504: 2003 Para La Evaluación De La Madurez De Procesos Software En Países En Desarrollo', IEEE Latin America Transactions, 4 (2006), 17-24. 48 Francisco J Pino, Félix García, Manuel Serrano, and Mario Piattini, 'Medidas Para Estimar El Rendimiento Y Capacidad De Los Procesos Software De Conformidad Con El Estándar Iso/Iec 15504-5: 2006', Revista Española de Innovación, Calidad e Ingeniería del Software, 2 (2006). 49 RELAIS, 'Actividades - Red Latinoamericana De La Industria Del Software ) Consulta: 29 de noviembre de 2013. 50 ———, 'La Red Latinoamericana De La Industria Del Software - Relais) Consulta: 29 de diciembre de 2013. 51 Ita Richardson, and Kevin Ryan, 'Software Process Improvements in a Very Small Company', Software Quality Professional, 3 (2001), 23-35. 52 Juan Carlos Vidal Rojas, Julio Ariel Hurtado Alegría, Francisco José Pino Correa, Hanna Oktaba, and Mario Piattini, 'Mejora De Procesos', Competisof (2006). 53 America Sistemas, 'Presentación De La Red Latinoamericana De La Industria Del Software - Sede En Uruguay) Consulta: 13 de diciembre de 2013. 54 SOFTEX, 'Guía General Mps De Software - Mps.Br'2012) Consulta: 27 de noviembre de 2013 . 55 SCAMPI Upgrade Team, 'Standard Cmmi Appraisal Method for Process Improvement (Scampi) a, Version 1.3: Method Definition Document', (2011). 56 Palomino Vásquez, and Marco Antonio Ibsen, 'Mejora Del Proceso De Una Pequeña Empresa Desarrolladora De Software: Caso Competisoft-Peru Lim. Lambda, Segundo Ciclo', (2011). 57 Mario Piattini Velthuis, 'Calidad De Sistemas De Información'2009) Consulta: 28 de noviembre de 2013 . 58 Dianne Britt Vergara González, 'Mejora Del Proceso Software De Una Pequeña Empresa Desarrolladora De Software: Caso Competisoft-Perú Lambda', (2008). 59 Helen Fiorela Zumaeta Liza, 'Implementación Del Nivel 1 Y 2 Del Moprosoft En Net Factory' (Universidad Peruana de Ciencias Aplicadas - UPC).