FACULTAD DE CIENCIAS EMPRESARIALES CARRERA PROFESIONAL DE INGENIERÍA DE SISTEMAS DE INFORMACIÓN Y GESTIÓN “PROPUESTA DE IMPLEMENTACION DEL AREA DE PROCESO DE VALIDACION Y VERIFICACION DEL CMMI V.1.3 UTILIZANDO METODOLOGIAS AGILES EN LA CONSULTORA DE SISTEMAS OFISIS” Tesis para Optar el Título Profesional de: Ingeniero de Sistemas de Información y Gestión Presentado por: BACH. RONALD GERARDO TRIGUEROS VARGAS LIMA – PERÚ 2015 i Dedicatoria Esta tesis se la dedico a mi Dios quién supo guiarme por el buen camino, darme fuerzas para seguir adelante y no desmayar en los problemas que se presentaban, enseñándome a encarar las adversidades sin perder nunca la dignidad ni desfallecer en el intento. Para mis padres Jorge Trigueros por sus consejos, y Rosa Vargas por su apoyo, consejos, comprensión, amor, ayuda en los momentos difíciles. Me han dado todo lo que soy como persona, mis valores, mis principios, mi carácter, mi empeño, mi perseverancia, mi coraje para conseguir mis objetivos. ii Agradecimientos A Dios por darme la fuerza y guiarme en el camino. A mis padres y hermanos por su paciencia y confianza. A mi amiga Paola Chacabana por su amistad y apoyo. A mis profesores por su invalorable aporte. iii ÍNDICE GENERAL DEDICATORIA .............................................................................................................. i AGRADECIMIENTO ......................................................................................................ii ÍNDICE GENERAL ....................................................................................................... iii INDICE DE FIGURAS ................................................................................................... iv ÍNDICE DE CUADROS ............................................................................................... viii ÍNDICE DE ANEXOS .................................................................................................... x RESUMEN ................................................................................................................... xii ABSTRACT ................................................................................................................ xiii INTRODUCCIÓN ........................................................................................................ xiv ÍNDICE GENERAL ............................................................................................................ iv CAPITULO I - PLANTEAMIENTO DEL PROBLEMA Y JUSTIFICACION .......................... 1 1.1. PLANTEAMIENTO DEL PROBLEMA ..................................................................... 2 1.2. JUSTIFICACIÓN ..................................................................................................... 2 1.2.1. JUSTIFICACIÓN TEÓRICA ..................................................................................... 2 1.2.2. JUSTIFICACIÓN PRÁCTICA ................................................................................... 3 1.3. DELIMITACIÓN Y ALCANCE ..................................................................................... 3 1.4. OBJETIVOS ................................................................................................................ 4 1.4.1. OBJETIVO GENERAL ............................................................................................. 4 1.4.2. OBJETIVOS ESPECÍFICOS .................................................................................... 4 1.5. ANTECEDENTES DE LA INVESTIGACIÓN ............................................................... 4 1.6. MARCO TEÓRICO ..................................................................................................... 4 1.6.1. METODOLOGÍAS ÁGILES ...................................................................................... 4 a. MANIFIESTO ÁGIL (AGILE MANIFESTO) .................................................................... 7 b. PROGRAMACIÓN EXTREMA (XP – EXTREME PROGRAMMING).............................. 7 c. CRYSTAL ...................................................................................................................... 8 d. DESARROLLO LEAN .................................................................................................... 8 e. SCRUM ......................................................................................................................... 9 1.6.2. CMM Y CMMI ........................................................................................................ 16 a. El marco de trabajo de CMMI ...................................................................................... 17 b. CMMI V1.3 para desarrollo .......................................................................................... 18 c. Madurez vs Inmadurez ................................................................................................. 19 1.6.3. REPRESENTACIÓN Y NIVELES........................................................................... 19 a. Representación por Etapas .......................................................................................... 19 1.6.4. ÁREAS DE PROCESO EN CMMI V1.3.................................................................. 22 a. VALIDACIÓN (VAL) ..................................................................................................... 22 b. VERIFICACIÓN (VER) ................................................................................................. 23 iv 1.6.5. INTERPRETAR CMMI V1.3 PARA LA UTILIZACIÓN DE METODOLOGÍAS ÁGILES............................................................................................................................ 23 1.7. EMPRESA ................................................................................................................ 24 1.7.1. DEFINICIÓN DE EMPRESA .................................................................................. 24 1.7.2. DEPARTAMENTOS ............................................................................................... 25 a. DEPARTAMENTO DE CONSULTORÍA ....................................................................... 25 b. DEPARTAMENTO DE CALIDAD ................................................................................. 25 c. DEPARTAMENTO DE DESARROLLO ........................................................................ 25 1.7.3. NORMAS GENERALES ........................................................................................ 25 1.7.4. SITUACION ACTUAL ............................................................................................ 26 1.8. HIPÓTESIS ............................................................................................................... 26 1.8.1. HIPÓTESIS NULA: ................................................................................................ 26 1.8.2. HIPÓTESIS SECUNDARIAS: ................................................................................ 27 CAPITULO II - MATERIAL Y MÉTODOS ......................................................................... 28 2.1. MATERIALES ........................................................................................................... 29 2.1.1. PRESENTA RELACIÓN DE PERSONAL, MATERIALES Y MEDIOS .................... 29 2.1.1.1. POBLACIÓN Y MUESTRA ................................................................................. 29 a. POBLACIÓN ................................................................................................................ 29 2.1.1.2. TÉCNICAS DE RECOLECCIÓN DE DATOS ...................................................... 29 a. ENCUESTAS ............................................................................................................... 29 b. ENTREVISTA .............................................................................................................. 30 c. OBSERVACIÓN DIRECTA .......................................................................................... 30 2.1.2. TIEMPO, EQUIPAMIENTO, SITUACIÓN Y EXIGENCIAS DEL PROBLEMA ........ 30 2.1.2.1. TIEMPO .............................................................................................................. 30 2.1.2.2. EQUIPAMIENTO ................................................................................................ 31 2.1.2.3. SITUACIÓN ........................................................................................................ 34 2.1.2.4. EXIGENCIA DEL PROBLEMA ............................................................................ 34 2.2. MÉTODOS ................................................................................................................ 35 2.2.1. PROCEDIMIENTOS O MÉTODOS ........................................................................ 35 2.2.2. DISEÑO DE INVESTIGACIÓN .............................................................................. 35 a. VARIABLES ................................................................................................................. 35 b. DEFINICIÓN OPERACIONAL DE LAS VARIABLES ................................................... 35 2.2.3. TIPO DE INVESTIGACIÓN .................................................................................... 36 a. DESCRIPTIVA ............................................................................................................. 36 b. EXPLICATIVA .............................................................................................................. 37 2.2.4. ENFOQUE DE INVESTIGACIÓN........................................................................... 37 v 2.2.5. DELIMITACIÓN Y DEFINICIÓN DE LA POBLACIÓN DE ESTUDIO ..................... 37 2.2.6. APLICAR CRITERIOS PARA SELECCIONAR MUESTRA DE ESTUDIO .............. 37 a. MUESTRA PROBABILÍSTICA ESTRATIFICADA ........................................................ 37 2.2.7. CRITERIOS DE INCLUSIÓN Y EXCLUSIÓN ........................................................ 38 a. CRITERIOS DE INCLUSIÓN ....................................................................................... 38 b. CRITERIOS DE EXCLUSIÓN ...................................................................................... 38 2.2.8. ANÁLISIS ESTADÍSTICO ...................................................................................... 38 CAPITULO III - RESULTADOS ........................................................................................ 40 3.1. REPRESENTACIÓN E INTERPRETACIÓN DE RESULTADOS .............................. 41 3.1.1. ENTREVISTA AL AREA DE CONSULTORIA ........................................................ 41 3.1.2. ENTREVISTA AL AREA DE CALIDAD .................................................................. 44 3.1.3. ENTREVISTA AL AREA DE DESARROLLO ......................................................... 49 3.2. DETERMINACIÓN DE LA MADUREZ DE LA ORGANIZACIÓN ............................... 52 3.2.1. DIAGNÓSTICO DE LA VALIDACIÓN .................................................................... 53 3.2.3. DIAGNÓSTICO GENERAL PARA DETERMINAR EL NIVEL DE MADUREZ DE LA ORGANIZACIÓN. ................................................................................................. 54 3.3. PRESENTACIÓN DE LA PROPUESTA .................................................................... 55 3.3.1. DESCRIPCIÓN DE LA PROPUESTA PARA IMPLANTAR EL PROCESO DE VALIDACIÓN Y VERIFICACIÓN ..................................................................................... 55 3.3.2. PREPARAR LA VALIDACIÓN (SG 1) .................................................................... 55 a. Seleccionar los productos a validar (SP 1.1) ................................................................ 55 b. Establecer el entorno de validación (SP 1.2)................................................................ 57 c. Establecer los procedimientos y los criterios de validación (SP 1.3) ............................ 57 3.3.3. VALIDAR EL PRODUCTO O LOS COMPONENTES DE PRODUCTO (SG 2) ...... 58 a. Realizar la validación (SP 2.1) .................................................................................. 58 b. Analizar los resultados de la validación (SP 2.2)....................................................... 59 3.3.4. PREPARAR LA VERIFICACIÓN (SG 1) ................................................................ 59 a. Seleccionar los productos de trabajo a verificar (SP 1.1) ............................................. 59 b. Establecer el entorno de verificación (SP 1.2) .............................................................. 60 c. Establecer los procedimientos y los criterios de verificación (SP 1.3) .......................... 61 3.3.5. REALIZAR REVISIONES ENTRE PARES (SG 2) ................................................. 61 a. Preparar las revisiones entre pares (SP 2.1) ............................................................ 62 b. Llevar a cabo las revisiones entre pares (SP 2.2) ..................................................... 62 c. Analizar los datos de la revisión entre pares (SP 2.3) ............................................... 63 3.3.6. VERIFICAR LOS PRODUCTOS DE TRABAJO SELECCIONADOS (SG 3) .......... 63 a. Realizar la verificación (SP 3.1) ................................................................................ 64 vi b. Analizar los resultados de la verificación (SP 3.2) ..................................................... 65 3.3.2 USO DE MÉTODOS AGILES PARA DAR SOPORTE AL PROCESO DE VALIDACIÓN Y VERIFICACIÓN ..................................................................................... 65 a. Reunión de planificación de la entrega y priorizar las tareas más criticas ................. 66 b. El Scrum interdiario .................................................................................................. 66 3.3.3. TRAZABILIDAD ENTRE LAS PRÁCTICAS ÁGILES Y LA VALIDACIÓN Y VERIFICACIÓN EN CMMI V1.3 ....................................................................................... 66 3.3.4. DIAGRAMA DE PROCESO PROPUESTO ............................................................ 68 a. DEFINICIÓN DEL PROCESO...................................................................................... 69 3.3.5. NIVEL DE MADUREZ DE LA ORGANIZACIÓN CON RESPECTO A LAS ÁREAS DE PROCESOS DE VALIDACIÓN Y VERIFICACIÓN DEL CMMI V1.3 NIVEL 3 ...................................................................................................................................... 71 3.3.6. ANÁLISIS POST DESARROLLO DE MODELO PROPUESTO .............................. 71 a. ANÁLISIS DE LA VALIDACIÓN ................................................................................... 71 b. ANÁLISIS DE LA VERIFICACIÓN ............................................................................... 72 3.6. NIVEL DE CUMPLIMIENTO DE PRÁCTICAS POR CADA ÁREA DE PROCESO .... 72 3.6.1. VALIDACIÓN ..................................................................................................... 72 3.6.2. VERIFICACIÓN ................................................................................................. 73 3.7. NIVEL DE MADUREZ DE LA ORGANIZACIÓN BASADO EN EL MODELO PROPUESTO .................................................................................................................. 74 3.8. PROPUESTA DE IMPLEMENTACIÓN DEL ÁREA DE PROCESO DE VALIDACIÓN Y VERIFICACIÓN DEL CMMI V1.3 SOPORTADO POR METODOLOGÍAS AGILES .............................................................................................. 74 3.8.2. ANALISIS DE OPORTUNIDAD .............................................................................. 77 CAPITULO IV - DISCUSIÓN ............................................................................................ 78 4.1. DISCUSIÓN .............................................................................................................. 79 CAPITULO V - CONCLUSIONES Y RECOMENDACIONES .................................................. 80 5.1. CONCLUSIONES ..................................................................................................... 81 5.2. RECOMENDACIONES ............................................................................................. 82 CAPITULO VI - REFERENCIAS BIBLIOGRÁFICAS ........................................................ 83 6.1. REFERENCIAS BIBLIOGRÁFICAS .......................................................................... 84 CAPITULO VII - GLOSARIO ............................................................................................ 85 7.1. GLOSARIO ............................................................................................................... 86 CAPITULO VIII - ANEXOS............................................................................................... 87 vii INDICE de Figuras, Gráficos y Esquemas Figura 1: Costo Relativo de corregir errores en distintas fases de ciclo de desarrollo de software expuesto por el profesor Barry Boehm durante la conferencia de Equity, Holanda, en Marzo del 2007 .............................................................................................. 7 Figura 2: Representación del Scrum ................................................................................ 16 Figura 3: Componentes de CMMI v1.3 ............................................................................ 18 Figura 4: Representación por Etapas ............................................................................... 21 Figura 5: Comparativo de Horas de Garantías de los años 2014-2015 ............................ 26 Figura 6: Respuesta pregunta 1 de consultoría ................................................................ 41 Figura 7: Respuesta pregunta 2 de consultoría ................................................................ 42 Figura 8: Respuesta pregunta 3 de consultoría ................................................................ 43 Figura 9: Respuesta pregunta 4 de consultoría ................................................................ 43 Figura 10: Respuesta pregunta 5 de consultoría .............................................................. 44 Figura 11: Respuesta pregunta 1 de calidad .................................................................... 45 Figura 12: Respuesta pregunta 2 de calidad .................................................................... 46 Figura 13: Respuesta pregunta 3 de calidad .................................................................... 46 Figura 14: Respuesta pregunta 4 de calidad .................................................................... 47 Figura 15: Respuesta pregunta 5 de calidad .................................................................... 48 Figura 16: Respuesta pregunta 6 de desarrollo ............................................................... 48 Figura 17: Respuesta pregunta 1 de desarrollo ............................................................... 49 Figura 18: Respuesta pregunta 2 de desarrollo ............................................................... 50 Figura 19: Respuesta pregunta 3 de desarrollo ............................................................... 50 Figura 20: Respuesta pregunta 4 de desarrollo ............................................................... 51 Figura 21: Respuesta pregunta 5 de desarrollo ............................................................... 51 Figura 22: Parte del Alcance Funcional ........................................................................... 56 Figura 23: Pantalla de control de tiempos ........................................................................ 56 Figura 24: Parte del entorno de trabajo ............................................................................ 57 Figura 25: Parte del Plan de Pruebas .............................................................................. 58 Figura 26: Parte del documento de pruebas .................................................................... 59 Figura 27: Parte del documento Caso de uso .................................................................. 60 Figura 28: Parte del Alcance de requerimiento ................................................................ 61 Figura 29: Parte del documento Revisión entre pares ...................................................... 64 Figura 30: Parte del documento Revisión entre pares ...................................................... 65 Figura 31: Diagrama de proceso propuesto ..................................................................... 68 viii Figura 32: Comparación Validación antes y después del modelo propuesto .................... 73 Figura 33: Comparación Verificación antes y después del modelo propuesto .................. 73 Figura 34: Comparación de horas de garantías de proyectos con la propuesta de tesis .. 76 Figura 35: Análisis de inconformidad del cliente por áreas de OFISIS ............................. 77 ix INDICE DE CUADROS Y TABLAS TABLAS Tabla 1: Pilares que sostienen toda implementación del control empírico de procesos ..... 9 Tabla 2: Características de los roles de Scrum ................................................................ 11 Tabla 3: Características de los bloques de tiempo de Scrum ........................................... 12 Tabla 4: Características de los artefactos de Scrum ........................................................ 15 Tabla 5: Tipos de CMMI ................................................................................................... 17 Tabla 6: Comparación de Madurez e Inmadurez ............................................................. 19 Tabla 7: Categoría y Nivel................................................................................................ 21 Tabla 8: Notas para ambientes agiles en las áreas de proceso de CMMI v1.3 ................ 24 Tabla 9: Población de estudio .......................................................................................... 29 Tabla 10: Muestra del estudio .......................................................................................... 29 Tabla 11: Cronograma de la investigación ....................................................................... 30 Tabla 12 – Equipamiento de Infraestructura .................................................................... 31 Tabla 13: Equipamiento de Documentación ..................................................................... 31 Tabla 14: Equipamiento de Modelamiento ....................................................................... 32 Tabla 15: Equipamiento de Comunicación ....................................................................... 32 Tabla 16: Equipamiento de Encuesta .............................................................................. 33 Tabla 17: Costos de Recursos Humanos ......................................................................... 33 Tabla 18: Costo de Equipos ............................................................................................. 33 Tabla 19: Costo de Software ............................................................................................ 33 Tabla 20: Costo de Servicio ............................................................................................. 33 Tabla 21: Costo Total del Proyecto .................................................................................. 34 Tabla 22: Definición operacional de variables .................................................................. 35 Tabla 23: Análisis Estadístico .......................................................................................... 39 Tabla 24: Rango de estados ............................................................................................ 52 Tabla 25: Metas y Prácticas específicas de Validación .................................................... 53 Tabla 26: Mestas y Practicas específicas de la verificación ............................................. 53 Tabla 27: Tiempos estimados de documentación, desarrollo y calidad ............................ 62 Tabla 28- Trazabilidad entre las prácticas ágiles y validación en CMMI v1.3 ................... 66 Tabla 29 - Trazabilidad entre las prácticas ágiles y verificación en CMMI v1.3 ................ 67 Tabla 30: Definición del Proceso Propuesto .................................................................... 69 Tabla 31: Análisis de Validación del Modelo Propuesto ................................................... 71 Tabla 32: Análisis de Verificación del Modelo Propuesto ................................................. 72 x Tabla 33: Clientes que optaron por trabajar con otro proveedor ...................................... 75 Tabla 34: Comparación de horas de garantías de proyectos con la propuesta de tesis. .. 76 xi INDICE ANEXOS Anexo A - Encuesta para Calidad .................................................................................... 88 Anexo B - Encuesta para Consultoría .............................................................................. 89 Anexo C - Encuesta para Desarrollo ................................................................................ 90 Anexo N° 1 - REVISION ENTRE PARES......................................................................... 91 Anexo N° 2 - PLAN ESPECÍFICO DE MEJORA .............................................................. 96 Anexo N° 3 - ALCANCE DE REQUERIMIENTO .............................................................. 97 Anexo N° 4 - ESTANDARES DE NOMBRES ................................................................. 100 Anexo N° 5 - BASE DE DATOS (LOGICO) .................................................................... 108 Anexo N° 6 - BASE DE DATOS (FISICO) ...................................................................... 110 Anexo N° 7 - STORED PROCEDURES ......................................................................... 112 Anexo N° 8 - PROGRAMA CLIENTE (APT) ................................................................... 116 Anexo N° 9 - REPORTES .............................................................................................. 119 Anexo N° 10 - PLAN DE PRUEBAS .............................................................................. 123 Anexo N° 11 - ALCANCE FUNCIONAL ........................................................................ 125 xii Resumen En esta propuesta se investiga los procesos de validación y verificación del área de Calidad para la empresa Consultora OFISIS, que brinda soluciones ERP que busca el brindar un producto con mayor calidad y cumplir con las necesidades de nuestros clientes. En la actualidad las empresas en general tiende a ser competitivas, la evolución y el continuo crecimiento de las tecnologías de la información, así como la sociedad que se vuelve más demandante cada día exigiendo productos y/o servicios con mayor calidad, por lo que calidad implica la utilización de metodologías o procedimientos estándares para el análisis, diseño, programación y pruebas del software que permitan uniformar la filosofía de trabajo, en áreas de lograr una mayor confiabilidad, mantenibilidad y facilidad de pruebas, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. Los problemas observados en la Consultoría OFISIS a pesar de haber obtenido la certificación de CMMI nivel 3 en la actualidad con el pasar de los años el área de calidad dejo de utilizar la metodología establecida perdiendo así la mejora continua de procesos y certificaciones obtenidas. Generando que se supere los tiempos de entrega planificados al cliente, e invirtiendo mayor recursos de lo planificado originando una propuesta no rentable para la empresa. Los datos analizados sugieren que se debe de utilizar una metodología de mejora de procesos en el cual se realice un seguimiento y validación continua a los desarrollos entregados al cliente. Por lo cual debemos de utilizar las metodologías de CMMI y Agiles para obtener el seguimiento continuo de los desarrollos. Sin embargo los métodos agiles no plantean lineamientos formales para identificar los problemas potenciales es aquí donde CMMI juega un rol importante, que propone un conjunto de mejores prácticas para cubrir el ciclo de vida de un proceso de desarrollo de software. En conclusión se propone se haga uso de la integración de ambas metodologías para mejorar con los procesos de validación y verificación del área de Calidad, logrando así optimizar los tiempos de entrega de los desarrollos al cliente y a la vez la calidad del producto. Palabras Claves: Metodología Ágil, CMMI, control de calidad, validación, verificación xiii Abstract In this proposal, the validation and verification processes of the quality area for OFISIS consulting company that provides ERP solutions and seeks to provide a product with higher quality and meeting the needs of our customers are investigated. Nowadays, companies tend to be competitive. The evolution and continued growth of information technology and society, every day demands products and / or services with higher quality. Therefore, quality involves the use of standard procedures and methodologies for the analysis, design, programming and testing of software to standardize the work philosophy in areas achieve greater reliability, maintainability and ease of testing, while that raise productivity, both for development and for the quality control software. The problem observed in OFISIS, despite having been certified CMMI Level 3, is that the quality area stopped using the methodology established thus losing the continuous improvement of processes and certifications. This led to the planned delivery times and increased customer spending planned resources causing an unprofitable proposal for the company is exceeded. The analyzed data suggest that it should use a method of improving processes in which continuous monitoring and developments delivered to the customer validation is performed. Therefore, we must use the CMMI and Agile methodologies for continuous monitoring of developments. However, agile methods pose no formal guidelines for identifying potential problems it is here that plays an important role CMMI latter proposes a set of best practices to meet the life cycle of a software development process. In conclusion, it is proposed that use of the integration of both methodologies to improve the validation and verification of Quality area, achieving optimize delivery times and customer developments while product quality is made. Key words: Agile methodology, CMMI, quality control, validation, verification xiv INTRODUCCIÓN En la actualidad, la consultora de sistemas OFISIS no cuentan con una adecuada control de calidad de los productos que desarrolla, es por ello que muchas veces el personal de Consultoría que implementa los desarrollos, se ve con problemas de validación con el cliente o los tiempos de entrega del producto son entregados después de lo planificado, originando que la calidad del servicio que se ofrece disminuya ante sus clientes directos o finales. Es por ello, que tomando en cuenta esta necesidad en el área de Tecnología de Información de la consultora de sistemas OFISIS, se presenta el siguiente trabajo, para poder tener procesos definidos de validación y verificación con una visión de organización para optimización del control de calidad. Para el análisis de los procesos anteriormente mencionados, el presente trabajo se basara en las mejores prácticas recomendadas CMMI v1.3 utilizando metodología Agiles. La tesis busca resolver alguno de los problemas detectados dentro de la organización, con el principal objetivo de cambiar la forma como el área de calidad valida los desarrollos entregados por TI, para lograrlo debemos diseñar procesos que permitan superar las deficiencias que actualmente existe. De esta manera OFISIS contara con metodologías que garantizan la eficiencia en la utilización de los recursos, reducciones de cotos, y además podrá controlar el crecimiento caótico que se está dando. CAPÍTULO I. “PLANTEAMIENTO DEL PROBLEMA Y JUSTIFICACION”, en este capítulo se identifica el Problema a investigar que está aconteciendo en la consultora de sistemas OFISIS, para lo cual delimitamos sus alcances, justificamos debidamente el problema y planteamos los objetivos, los mismos que serán la guía de todo el proyecto. “Marco Teórico”, en este capítulo presenta el fundamento teórico el cual ayuda a comprender de una forma clara el problema, para posteriormente plantear una propuesta de solución al mismo. CAPÍTULO II. “MATERIAL Y METODOS”, se describen las Modalidades de Investigación a seguir para conseguir el resultado inicialmente propuesto, así como también la forma de cómo se recolectará y se procesará la información y finalmente el esquema a aplicar para el Desarrollo de la investigación. CAPÍTULO III. “RESULTADOS”, en este capítulo se describe el desarrollo de la propuesta de solución, definiendo los requisitos necesarios ante el problema planteado CAPÍTULO IV. “DISCUSIONES”, presenta los puntos de vista y críticas que se ha llegado con la investigación realizada luego del desarrollo del proyecto. CAPÍTULO V. “CONCLUSIONES Y RECOMENDACIONES”, presenta las conclusiones que se ha llegado con la investigación realizada luego del desarrollo del proyecto, de la misma forma se hacen las recomendaciones que se ha considerado necesarias. xv Concluimos el presente trabajo con las referencias bibliográficas citadas en este documento y los anexos con documentación utilizada para el desarrollo del presente trabajo. xvi CAPITULO I - PLANTEAMIENTO DEL PROBLEMA Y JUSTIFICACION 1 1.1. PLANTEAMIENTO DEL PROBLEMA En la actualidad la Consultora de Sistemas OFISIS cuenta con la certificación internacional de calidad CMMI nivel 3 obtenida en el año 2011; actualmente está en proceso de revalidación. Hoy en día el área de calidad no está aplicando la metodología establecida, lo cual está generando problemas en los tiempos de entrega de los desarrollos, validación y verificación de los mismos. Por otro ladoel área de consultoría al no plasmar todo el requerimiento del cliente detalladamente causa ambigüedades de los desarrollos a entregar. Así mismo, el área de desarrollo no supervisa los desarrollos de los programadores causando pérdida de tiempo entre el área de calidad y el área desarrollo. Esta situación genera a diario que el área de consultoría devuelva los desarrollos al área de calidad por que no se realizaron la validación de todas las casuísticas del desarrollo en cuestión, provocando que se supere el tiempo de entrega planificada al cliente, y por ende invirtiendo más recursos de lo planificado originando una propuesta no rentable para la empresa (un costo de inversión) e insatisfacción del cliente. Para plantear una respuesta a la situación actual, se propone diseñar e implantar el proceso de validación y verificación de los productos desarrollados en OFISIS orientado a satisfacer la meta genérica y las prácticas genéricas del nivel de capacidad 3 para el área de proceso de validación y verificación de CMMI v1.3 adoptando prácticas ágiles. Así mismo, sugerimos que se revalide la certificación internacional de calidad CMMI dado que la última certificación fue en el año 2011. Se busca poder demostrar de esta forma que se puede identificar, monitorear, controlar y minimizar la probabilidad de ocurrencia de ciertas garantías del producto, así como también su entrega temprana del producto, y dejar en evidencia que existe una estrategia de validación y verificación institucionalizada dentro de la organización. Esta solución se puede utilizar como ejemplo para adoptarla en otras áreas de la organización, considerando que el desarrollo de productos es crítico hoy en día y un impacto negativo en el mercado puede afectar considerablemente la imagen de la empresa y los resultados económicos. 1.2. JUSTIFICACIÓN 1.2.1. JUSTIFICACIÓN TEÓRICA Diversas investigaciones aplicadas o de modelamiento de negocios han permitido demostrar que la implementación de la metodología del CMMI es ayudo en la mejora de sus procesos de aseguramiento y control de la calidad, reduciendo el re-trabajo al mejorar la planificación y seguimiento, la comunicación, las responsabilidades, y la detección temprana de errores. Generando una Base de Conocimiento con la 2 ejecución de los procesos y los proyectos, la cual es muy rica e importante para la organización. La metodología Ágil trae consigo diversos beneficios, pues permite una mayor flexibilidad que las metodologías tradicionales (en cascada e interactivas), debido a que éstas son menos capaces a ajustarse a las cambiantes necesidades de los clientes, del mercado, y de los nuevos desafíos que plantea la tecnología. 1.2.2. JUSTIFICACIÓN PRÁCTICA La aplicación de la integración de la metodología CMMI y Ágil permitirá el aseguramiento de la calidad de los desarrollos y optimización de los procesos de tiempos de entrega, mediante el cumplimiento de los procedimientos que serán expresados en documentos que contienen el objetivo y las actividades que deben hacerse y quien debe hacerlo, cuando, donde y como debe llevarse a cabo; los recursos y documentos que deben utilizarse. 1.3. DELIMITACIÓN Y ALCANCE Esta propuesta está dirigida para la empresa en estudio que busca resolver sus problemas en los procesos de calidad del desarrollo de software y tiempos de entrega de los mismos, para lo cual se considera dentro del alcance lo siguiente:  Análisis y Desarrollo del modelo propuesto de mejora de procesos en base al Modelo CMMI v1.3 enfocado específicamente a las áreas de procesos: Validación (VAL), Verificación (VER).  Análisis y Desarrollo del modelo propuesto de mejora de procesos en base a la metodología ágil enfocado específicamente en SCRUM. Por otro lado no se contempla dentro del alcance la implementación del modelo y del sistema propuesto. 3 1.4. OBJETIVOS 1.4.1. OBJETIVO GENERAL El desarrollo de esta investigación tiene como objetivo principal aplicar la integración de la metodología de Gestión de calidad CMMI y Ágil para implementar en los procesos de tiempos de entrega y desarrollo de los productos en la consultora de Sistemas OFISIS. 1.4.2. OBJETIVOS ESPECÍFICOS Los objetivos específicos que se persiguen en esta investigación son:  Investigar los marcos de referencia del CMMI v1.3 y la metodología ágil.  Reducir las garantías del producto en un 25%.  Mantener un alto nivel de satisfacción del cliente al entregar un producto de calidad y en el tiempo planificado. 1.5. ANTECEDENTES DE LA INVESTIGACIÓN La Consultora de Sistemas OFISIS no está aplicando actualmente la metodología de CMMI obtenida en el año 2011. Esta falta de aplicación de metodología se vio reflejado en el área de calidad debido a que sufrió un cambio en la estructura organizacional de la empresa en el año 2012 por la incorporación a un grupo corporativo SOFTLAND. Así también, el área de consultoría no solo no detalle el alcance de requerimiento del cliente sino que muchas veces no entrega los casos de prueba que deben de realizar el área de calidad con respecto al desarrollo, originando una inadecuada validación del desarrollado o iteración de entregables entre el área de calidad y consultoría. Otra dificultad que tiene afrontar el área de calidad es la falta de supervisión de los productos entregados por el área de desarrollado, conllevando a otra iteración de los entregables entre el área calidad y desarrollo. 1.6. MARCO TEÓRICO 1.6.1. METODOLOGÍAS ÁGILES El desarrollo de software, según Martin Fowler en su artículo “La Nueva Metodología (The New Methodology)” escrito en diciembre del 2005, “se conoce como una actividad caótica caracterizada por la frase codificar y corregir. El software muchas veces se escribe sin seguir un plan y el diseño del mismo depende de decisiones de corto plazo. Esto puede funcionar cuando se trata de un sistema pequeño, pero en la medida que el tamaño del software es mayor resulta más complejo añadir nuevas funcionalidades, 4 aumenta la cantidad de errores y la dificultad para corregirlos. Una típica señal de esto son largas fases de pruebas una vez que las características principales del sistema hayan sido desarrolladas”. El movimiento original que trató de cambiar esta forma de trabajar, introdujo la noción de metodología. Estas metodologías exigen un proceso disciplinado con la finalidad de tener un proceso de desarrollo más eficiente y predecible. La idea principal consiste en disponer de un proceso detallado con un fuerte énfasis en la “planificación” inspirado por otras disciplinas de la ingeniería. La presencia y uso de estas metodologías ha estado vigente por muchos años. No han sido notorias necesariamente por proveer excelentes resultados o incluso por ser populares en su uso. Tal vez la crítica más frecuente con respecto a éstas es que son “burocráticas”, ya que se considera que demandan tantos requisitos que se disminuye el rendimiento y la velocidad del proceso de desarrollo de software. Como reacción a este movimiento surgieron las metodologías ágiles. Para muchos la aparición de las metodologías ágiles es la reacción a la demandante burocracia exigida por las metodologías con énfasis en la planificación y basadas en otras disciplinas de la ingeniería. Estas buscan proveer una alternativa entre no tener algún proceso o disponer de muchos procesos, y que se alcancen los objetivos de manera razonable. El resultado de todo esto es que las metodologías ágiles tienen algunos cambios significativos en comparación con las metodologías tradicionales. Tal vez los cambios más significativos son considerados los siguientes:  Los métodos agiles son adaptativos y no predictivos. Las metodologías tradicionales buscan crear un plan a largo plazo y en gran detalle con respecto al proceso de desarrollo de software de un proyecto particular, lo que funciona bien hasta que el proyecto comienza a sufrir variaciones en su alcance. Por lo tanto, su naturaleza no contempla el cambio constante. Por otra parte, los métodos ágiles contemplan el cambio como algo normal, adaptándose a estos con frecuencia.  Los métodos agiles están orientados a las personas y no orientados a los procesos. Las metodologías tradicionales definen un proceso que busque satisfacer las necesidades de un proyecto, independientemente de qué individuo lo utilice. Las metodologías ágiles se basan en que no hay proceso que supere las habilidades del equipo de desarrollo. Por lo tanto, el rol del proceso es servir de soporte al equipo de desarrollo y no viceversa.  Los métodos agiles son menos orientados a la documentación. Las metodologías tradicionales promueven el desarrollo de planes y distintos tipos de documentos dependiendo de la fase del proceso en 5 que se encuentre el proyecto. En cambio, las metodologías ágiles promueven la idea de que el código del software en desarrollo por sí mismo debería ser la documentación existente.  Los métodos agiles consideran la participación del cliente durante el desarrollo como esencial. La mayor parte del tiempo las características del sistema con mayor valor agregado para el negocio no son tan obvias en un principio, sino una vez que el cliente empieza a utilizar el mismo. Por eso las metodologías ágiles buscan tomar ventaja con esto, ya que permiten a los clientes aprender de sus necesidades de negocio en la medida que se construye el software y así ir desarrollando este de tal forma que los cambios puedan ser incorporados rápidamente. Una característica de las metodologías ágiles es el hecho de que son iterativas. La clave del desarrollo iterativo es proveer partes funcionales y operativas de un conjunto de funcionalidades del software que se encuentra en construcción y por lo tanto del sistema final. Cada una de las funcionalidades a proveer debe estar probada y ser integrada bajo las mismas condiciones como si fuese la entrega del sistema final. El punto de trabajar con iteraciones es que se ha comprobado que es realmente productivo ya que el cliente se puede sentar frente al sistema y empezar a utilizarlo y es cuando nuevos defectos o la mala interpretación que pudo existir de algún requerimiento se manifiesta y es visible para el proyecto, lo que permite tomar acción rápidamente y no esperar hasta la entrega de un producto final, donde el costo de corregir errores se incrementa considerablemente. A continuación en el Gráfico se puede observar la relación del costo de corregir errores en el software en las distintas fases del ciclo de desarrollo. Costo relativo de corregir un error según la fase del ciclo de desarrollo donde se repare 150 100 50 0 Req Design Code Devt AccT Ops FASE DEL CICLO DE DESARROLO DE SOFTWARE 6 COSTO RELATIVO DE SOLUCIONAR ERROR Figura 1: Costo Relativo de corregir errores en distintas fases de ciclo de desarrollo de software expuesto por el profesor Barry Boehm durante la conferencia de Equity, Holanda, en Marzo del 2007 a. MANIFIESTO ÁGIL (AGILE MANIFESTO) El 13 de febrero del 2001 en el alojamiento Snowbird Sky Resort en las montañas Wasatch en Utah, 17 personas se reunieron para conversar, esquiar y relajarse. Entre estas personas se encontraban Kent Beck, Alistair Cockburn y Martin Fowler, entre otros. La idea de la reunión era tratar aspectos y compartir ideas sobre procesos para el desarrollo de software que estaban surgiendo como alternativa a las metodologías de desarrollo de software tradicionales, que consideraban como pesadas, rígidas y altamente dependientes de planificaciones detalladas previas al desarrollo. Como resultado de esta reunión, nace lo que se denomina el “Manifiesto para el desarrollo de software Ágil” 8. Dentro de este manifiesto, se expone lo siguiente: “Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:  Individuos e Interacciones sobre procesos y herramientas.  Software funcionando sobre documentación extensiva.  Colaboración con el cliente sobre negociación contractual.  Respuesta ante el cambio sobre seguir un plan. Esto es, aunque valoramos los elementos de la derecha, valoramos más los elementos de la izquierda.” b.PROGRAMACIÓN EXTREMA (XP – EXTREME PROGRAMMING) El origen de la programación extrema proviene de principios de los años 90 cuando Kent Beck trató de encontrar una mejor forma de desarrollar software cuando se encontraba gestionando un proyecto en la empresa automotriz DaimlerChrysler. La programación extrema buscar mejorar un proyecto de software por medio de 5 dimensiones esenciales:  Comunicación: Los programadores extremos se comunican constantemente con sus clientes y con sus compañeros de trabajo.  Simplicidad: Los programadores extremos mantienen un diseño simple y limpio.  Retroalimentación: Los programadores extremos obtienen retroalimentación probando el software desde el primer día en que se empieza a construir el mismo. Adicionalmente, entregan 7 el software lo más temprano posible a sus clientes e implementan los cambios sugeridos por estos últimos.  Respeto: Cada pequeño éxito depende de cada contribución de los miembros del equipo.  Coraje: Los miembros del equipo tienen como reto responder a los cambios de requisitos y tecnologías durante el proyecto. c. CRYSTAL Crystal se conoce como una familia de metodologías de desarrollo de software propuestas por Alistair Cockburn a partir de 1991. Las metodologías Crystal se basan en el hecho de que hay que tener en cuenta las características del proyecto para aplicar una metodología. No es lo mismo un proyecto en el que intervienen pocas personas que otros en donde intervienen muchas. Creer que todos los proyectos son iguales independientemente de su tamaño es un error que puede derivar desde pérdidas económicas hasta el fracaso completo. El nombre Crystal deriva de la caracterización de los proyectos según 2 dimensiones, tamaño y complejidad (como en los minerales, color y dureza). Las metodologías Crystal van, en función del tamaño del equipo de proyecto, denominándose con colores más oscuros y en función de la criticidad por la dureza del cristal (en alusión al mineral), de manera que se tiene:  Metodología Crystal Clear (equipos hasta seis personas).  Metodología Crystal Amarillo (equipos entre seis y veinte personas).  Metodología Crystal Anaranjado (equipos entre veinte y cuarenta personas).  Metodología Crystal Rojo (equipos entre cuarenta y ochenta personas).  Crystal Marrón (equipos entre ochenta y doscientas personas).  Metodología Diamond y Sapphire en función de si del sistema depende la vida de las personas o la subsistencia de la organización. d. DESARROLLO LEAN La metodología de desarrollo “Lean” tiene sus raíces en el sistema de producción de la empresa automotriz Toyota y busca ayudar a las organizaciones que desarrollan software a optimizar sus procesos y métodos de producción con la finalidad de entregar productos más rápidamente y de mejor calidad. Los pioneros en la implementación de esta metodología en el mundo del desarrollo de software son Mary y Tom Poppendieck. Con el desarrollo “Lean”, el foco se encuentra sobre las personas y la comunicación, lo que quiere decir que si las personas que producen el software son respetadas y se comunican eficientemente, existe una 8 mayor probabilidad que se entregue un producto que logre satisfacer las necesidades de los clientes. e. SCRUM Scrum se ha utilizado para desarrollar productos complejos desde principios de los ‘90. Scrum no es un proceso o una técnica para desarrollar o crear productos de software, sino que es un marco en el que se pueden emplear diversos procesos y técnicas, a la vez que proporciona un marco dentro del cual se pueden desarrollar productos complejos. La historia y existencia de Scrum son el resultado de los esfuerzos en conjunto de Jeff Sutherland trabajando con Jeff McKenna y por otra parte de Ken Schwaber con Mike Smith y Chris Martin y fue presentado formalmente por primera vez y publicado en OOPSLA (Conferencia anual de aplicaciones, sistemas, lenguajes y programación orientada a objetos) en 1995. Scrum, que se basa en la teoría del control empírico de procesos, emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar los riesgos. La tabla muestra los pilares fundamentales del control empírico de procesos. Tabla 1:Pilares que sostienen toda implementación del control empírico de procesos Pilar Definición Transparencia  La transparencia garantiza que los aspectos del proceso que afectan al resultado, son visibles para aquellos que administran dicho resultado. Estos aspectos no sólo deben ser transparentes, sino también conocidos. Es decir, cuando alguien que inspecciona un proceso cree que algo está hecho, esto debe ser equivalente a su definición de “hecho”. Inspección  Se deben inspeccionar con la frecuencia suficiente los diversos aspectos del proceso para que puedan detectarse variaciones inaceptables en el mismo.  La frecuencia de inspección debe tener en cuenta que todos los procesos se cambian por el propio acto de inspección. El dilema se presenta cuando la frecuencia de inspección requerida excede la tolerancia del proceso a ser inspeccionado. Afortunadamente, esto parece no aplicar al desarrollo de software. El otro factor es la habilidad y la diligencia de la gente que inspecciona los resultados del trabajo. 9 … continuación Adaptación  Si el inspector determina, a través de la inspección, que uno o más aspectos del proceso están fuera de los límites aceptables, y que el producto resultante será inaceptable, debe ajustar el proceso o el material procesado. El ajuste debe realizarse lo más rápidamente posible para minimizar una desviación mayor. FUENTE: La Guía del Scrum El marco de Scrum se compone de un conjunto de equipos de Scrum y sus roles asociados; así como de bloques de tiempo, artefactos y reglas. Los equipos Scrum están diseñados para optimizar la flexibilidad y la productividad, para lo cual, son auto-gestionados, multifuncionales, y trabajan en iteraciones. Cada equipo Scrum tiene tres roles:  El Scrum Master (Facilitador).  El Propietario del Producto.  El Equipo Scrum. Scrum emplea bloques de tiempo para crear regularidad. Los elementos de Scrum basados en bloques de tiempo son:  La Reunión de Planificación de la Entrega.  El Sprint.  La Reunión de Planificación del Sprint.  La Revisión del Sprint.  La Retrospectiva del Sprint.  El Scrum Diario. Scrum emplea 3 artefactos principales, los cuales se mencionan a continuación:  El Product Backlog.  El Sprint Backlog.  El Burndown de la entrega. En cuanto a las “reglas” en Scrum, estas sirven de unión para los bloques de tiempo, los roles y los artefactos de Scrum. Por ejemplo, una regla de Scrum es que sólo los miembros del equipo – la gente comprometida en convertir el Product Backlog en un incremento – pueden hablar durante un Scrum Diario. La Tabla muestra las características de los roles de Scrum. También la Tabla muestra las características de los bloques de tiempo de Scrum y en cuanto a la Tabla muestra las características de los artefactos de Scrum. 10 Tabla2: Características de los roles de Scrum Rol Características Scrum  Es responsable de asegurar que el equipo Scrum Master adhiere a los valores, prácticas y normas Scrum.  Ayuda a que el equipo Scrum y la organización adopten Scrum.  Enseña al equipo Scrum mediante entrenamiento y liderándolo para que sea más productivo y a que construya productos de mayor calidad. Ayuda a que el equipo Scrum comprenda y utilice la autogestión y a ser multidisciplinario. Propietario  Es la única persona responsable de gestionar el del Producto Product Backlog y asegurar el valor del trabajo que el equipo lleva a cabo.  Mantiene el Product Backlog y asegura la visibilidad del mismo para todos. Contribuye a que todo el mundo conozca qué elementos tienen la máxima prioridad y en qué se va a trabajar.  Es una persona, no un comité. Si existe un comité, este debe ser capaz de convencerle para cambiar la prioridad de un elemento.  Para que tenga éxito, todos en la organización deben respetar sus decisiones. Nadie está autorizado a obligar al equipo a trabajar bajo un conjunto diferente de prioridades, y a los equipos no se les permite prestar atención a nadie que diga lo contrario. El Equipo  Convierte el Product Backlog en incrementos de Scrum funcionalidad potencialmente entregables en cada Sprint.  Debe ser multifuncional. Los miembros del equipo deben tener todas las habilidades necesarias para crear un incremento de trabajo.  Los miembros deben tener habilidades especializadas, como la programación, el control de calidad, el análisis de negocio, la arquitectura, el diseño de la interfaz de usuario, bases de datos, entre otros.  Todo el mundo interviene, incluso si eso requiere aprender nuevas habilidades o recordar las antiguas. Las personas que se niegan a escribir código, ya que son arquitectos o diseñadores, no se ajustan bien al equipo.  Debe ser capaz de auto-organizarse. Nadie – ni siquiera el Scrum Master – dice al equipo cómo convertir el Product Backlog en incrementos de funcionalidad entregable. El equipo busca por su cuenta la mejor forma de hacerlo. 11 … continuación  No existen sub-equipos dedicados a áreas particulares.  El tamaño óptimo para un equipo es de siete personas, más o menos dos. Si hay más de nueve miembros, el problema simplemente es que se necesita demasiada coordinación. FUENTE: La Guía del Scrum Tabla 3: Características de los bloques de tiempo de Scrum Bloque de Características Tiempo Reunión de  El propósito de la planificación de la entrega es Planificación establecer un plan y unas metas que los equipos de la Entrega Scrum y el resto de las organizaciones puedan entender y comunicar.  Responde a las preguntas: “¿Cómo podemos convertir la visión en un producto ganador, de la mejor manera posible? ¿Cómo podemos alcanzar o mejorar la satisfacción del cliente deseada y el Retorno de la Inversión?”.  Establece el objetivo de la entrega, el Product Backlog de mayor prioridad, los principales riesgos, y las características generales y la funcionalidad que va a contener la entrega.  Establece una fecha probable de entrega, y el coste, que debería mantenerse si no cambia nada. Sprint  Representa una iteración.  No se realizan cambios que afecten al objetivo del Sprint.  La composición del equipo se mantiene constante durante todo el Sprint.  Se componen de: la Reunión de Planificación de Sprint, el trabajo de desarrollo, la Revisión del Sprint, y la Retrospectiva del Sprint.  Puede ser cancelado antes de que el bloque de tiempo del Sprint se haya terminado. Sólo el Propietario del Producto tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de los interesados, del equipo, o del Scrum Master. ¿Bajo qué tipo de circunstancias puede un Sprint ser cancelado? La gerencia puede necesitar cancelar un Sprint si el objetivo del Sprint queda obsoleto. Esto podría ocurrir si la empresa cambia de dirección, o si cambia el mercado o las condiciones de la tecnología. Las cancelaciones de Sprints son a menudo traumáticas para el equipo, y muy poco frecuentes. 12 … continuación Reunión de  Durante la reunión la iteración del Sprint es Planificación planificada. del Sprint  La reunión se restringe a un bloque de tiempo de ocho horas para un Sprint de un mes. Para Sprints más cortos, se debería reservar para esta reunión un tiempo proporcionalmente menor, aproximadamente el 5% de la longitud total del Sprint (por ejemplo, para un Sprint de dos semanas sería una Reunión de Planificación de cuatro horas).  La Reunión consta de dos partes. La primera parte, que representa el “¿Qué?”, es cuando se decide qué se hará durante el Sprint. La segunda parte, que representa el ¿Cómo?, es cuando el equipo determina cómo se va convertir una funcionalidad en un incremento del producto durante el Sprint.  El equipo de Scrum trabaja en conjunto con el Propietario del Producto para determinar qué funciones se van a desarrollar durante el próximo Sprint.  La información de entrada para esta reunión es el Product Backlog, el último incremento del producto, la capacidad del equipo y el rendimiento anterior del equipo.  Sólo el equipo puede evaluar lo que puede lograr en el próximo Sprint. Es decisión de este. Revisión del  Se lleva a cabo al final del Sprint. Tiene una Sprint duración aproximada de 4 horas para un Sprint de un mes.  Es una reunión informal en la que el Equipo Scrum y las partes interesadas debaten sobre lo que se acaba de hacer. En base a eso, y a los cambios en el Product Backlog que se hayan hecho durante el Sprint, colaboran para determinar las próximas cosas que se podrían hacer.  El Propietario del Producto identifica lo que se ha hecho y lo que no se ha hecho. El equipo analiza lo que salió bien durante el Sprint y cuáles son los problemas que encontró, y cómo resolvió estos problemas.  El Equipo Scrum muestra el trabajo que ha sido completado y responde preguntas. El Propietario del Producto analiza el Product Backlog en su estado actual y proyecta las fechas probables de finalización con distintos supuestos de velocidad para la siguiente reunión de Planificación del Sprint. 13 … continuación Retrospectiva  Se realiza después de la Revisión del Sprint y del Sprint antes de la Reunión de Planificación del Sprint y tiene una duración aproximada de 3 horas para un Sprint de un mes.  El Scrum Master alienta al Equipo Scrum a revisar, en el marco de proceso y prácticas de Scrum, su proceso de desarrollo, para que sea más eficaz y agradable para el próximo Sprint.  Tiene como propósito inspeccionar cómo fue el último Sprint en lo que respecta a las personas, relaciones, procesos y herramientas. Por ejemplo, identificar y priorizar los elementos que si se hiciesen de forma diferente podrían producir mejoras, tales como las reuniones, herramientas, métodos de comunicación, la definición de lo “hecho”, entre otros.  La salida resultante son acciones de mejora a implementar durante el próximo Sprint. Scrum Diario  Todos los días el Equipo Scrum se reúne 15 minutos en una reunión de inspección y adaptación.  Se lleva a cabo a la misma hora y en el mismo lugar durante todos los Sprints.  Durante la reunión, cada miembro del equipo, explica: lo que ha conseguido hacer desde la última reunión; lo que va a hacer hasta la próxima reunión, y qué obstáculos tiene en su camino.  Mejora las comunicaciones, elimina otras reuniones, identifica y elimina los impedimentos al desarrollo, destaca y promueve la rápida toma de decisiones y mejora el nivel de conocimiento de los proyectos.  El Scrum Master se asegura de que el Equipo mantiene la reunión.  El Equipo es responsable de conducir el Scrum Diario.  No es una reunión de seguimiento del proyecto, sino sólo para la gente que trabaja en transformar los elementos del Product Backlog en un incremento. FUENTE: La Guía del Scrum 14 Tabla 4:Características de los artefactos de Scrum Artefacto Características Product  Es una lista de los requisitos del producto que se está Backlog desarrollando. Nunca está completo, cambia constantemente ya que se incluyen correcciones, nuevas funciones, tecnologías, entre otros y evoluciona en la medida que el producto evoluciona.  Los elementos del Product Backlog deben tener los siguientes atributos: una descripción, una prioridad, y una estimación.  Está ordenado por prioridad. La parte más prioritaria determina las actividades de desarrollo que se llevarán a cabo de forma inmediata.  Sólo los elementos de mayor prioridad se encuentran de forma detallada, en especial los que el equipo de Scrum ocupará durante el próximo Sprint.  El equipo Scrum es responsable de la estimación de todos los elementos, a pesar de que pueden contar con la ayuda del propietario del producto. Sprint  Se compone de las tareas que el equipo realiza para Backlog convertir los elementos del Product Backlog en un incremento “hecho”.  Constituyen todo el trabajo que el equipo identifica como necesario para cumplir con el Objetivo del Sprint.  Los elementos del Sprint Backlog deben descomponerse para ser entendidos durante el Scrum diario.  El tamaño normal para un elemento del Sprint Backlog en el que se está trabajando es de un día o menos.  El equipo modifica el Sprint Backlog a lo largo de todo el Sprint, así como la parte de Sprint Backlog adicional que surja durante el Sprint. Burndown  Es un gráfico que registra la suma del esfuerzo de la restante estimado del Product Backlog a lo largo Entrega del tiempo.  El esfuerzo se estima en cualquier unidad de trabajo que el equipo Scrum y la organización hayan decidido. Generalmente se utiliza el Sprint.  El Propietario del Producto mantiene publicados el Product Backlog y la gráfica de Burndown de Entrega actualizados en todo momento. Se puede trazar una línea de tendencia en la gráfica, basándose en el cambio en el trabajo restante. FUENTE: La Guía del Scrum 15 Figura 2: Representación del Scrum 1.6.2. CMM Y CMMI Un modelo de capacidad y madurez (CMM – Capacity Maturity Model) es una representación simplificada de un entorno y contiene los elementos de procesos efectivos basados en los conceptos desarrollados por Crosby, Deming, Juran y Humphrey13. En 1930, Walter Shewhart comenzó a trabajar en la mejora de procesos con sus principios de control estadístico de calidad. Estos principios fueron refinados por Edward Deming, Phillip Crosby y Joseph Juran. Watts Humphrey, Ron Radice y otros extendieron estos principios2 y empezaron a aplicarlos al software en trabajos de IBM (International Business Machines) y el SEI (Software Engineering Institute – Instituto de Ingeniería de Software de la Universidad de Carnegie Mellon) para el año de 1989. Posteriormente, el SEI creó el primer diseño de CMM para organizaciones de desarrollo de software y lo publicó en un libro denominado, “El modelo de capacidad y madurez: Guía para el mejoramiento continuo del proceso de Software” en el año 19952. Los modelos de capacidad y madurez (CMMs) se enfocan en la mejora de los procesos de una organización. Contienen elementos esenciales de procesos efectivos para una o más disciplinas describiendo un camino hacia el mejoramiento continuo que va desde procesos inmaduros a procesos disciplinados y maduros mejorando la calidad y efectividad. Tal como los modelos de capacidad y madurez, CMMI (Modelo de capacidad y madurez integrado) provee una guía de referencia a ser 16 utilizada para el desarrollo de los procesos de una organización. El modelo de capacidad y madurez integrado (CMMI), “no es un proceso o una descripción de procesos”. Cada organización dispone de procesos que dependen de distintos factores, bien sea por el dominio en el que se encuentra, su estructura o tamaño. Es por esta razón que no existe una relación de uno a uno entre el modelo y los procesos de una organización. CMMI busca ayudar a las organizaciones a identificar las fortalezas y debilidades de sus procesos y a promover cambios en dichos procesos con la finalidad de convertir aquellas debilidades en fortalezas. CMMI se aplica a equipos, grupos de trabajo, proyectos, divisiones y organizaciones enteras y está basado en un conjunto de mejores prácticas para mejorar la efectividad, eficiencia y calidad. a. El marco de trabajo de CMMI CMMI ofrece soluciones que ayudan a mejorar el rendimiento de las organizaciones y su habilidad para cumplir con los objetivos de negocio. El marco de trabajo de CMMI provee las personas, los modelos, los cursos de entrenamiento y los métodos de evaluación para medir objetivamente el progreso en las mejoras. Actualmente se proveen tres tipos o modelos de CMMI. Dichos modelos se basan en mejores prácticas y metas de mejoramiento continuo que las empresas utilizan para evaluarse y tratar de mejorar sus procesos. Estas metas y prácticas están organizadas en grupos intuitivos denominados “áreas de proceso”. La Tabla presenta los distintos tipos de CMMI. Tabla 5: Tipos de CMMI Tipo Descripción CMMI para Es un modelo que sirve de guía a las adquisiciones organizaciones en la gestión de la cadena de suministros, para adquirir e integrar productos y servicios y cumplir con las necesidades de los clientes. CMMI para desarrollo Es un modelo que sirve de guía para la mejora de procesos en organizaciones que desarrollan productos y servicios. CMMI para servicios Es un modelo que sirve de guía para organizaciones que establecen, gestionan y entregan servicios para satisfacer las necesidades de sus clientes y de los usuarios finales. FUENTE: CMMI para desarrollo, versión 1.3 17 Figura 3: Componentes de CMMI v1.3 Hoy en día CMMI se encuentra en su versión oficial 1.3 liberada durante el 2010 (http://www.sei.cmu.edu/library/assets/whitepapers/Spanish%20Techni cal%20Report%20CMMI%20V%201%203.pdf). La última versión oficial anterior a esta fue la 1.2 la cual fue liberada a partir del 2007. b. CMMI V1.3 para desarrollo El modelo propuesto por CMMI para desarrollo utiliza conceptos de gestión e ingeniería para ayudar en la entrega de productos a tiempo y de alta calidad, especialmente para aquellas organizaciones que dependen fuertemente del desarrollo de software. Este modelo cubre el ciclo de vida de productos y servicios desde la concepción de estos hasta la entrega y mantenimiento. Las prácticas que ofrece son flexibles para ser aplicadas a diferentes tipos de industrias y a la vez son estables y consistentes lo que a su vez sirve como una referencia contra laque la organización puede evaluarse y compararse a sí misma. Con la adopción de este modelo como guía de referencia, las organizaciones pueden lograr:  Mejorar la satisfacción del cliente.  Aumentar la calidad de los productos desarrollados. 18  Realizar las entregas en los tiempos acordados.  Minimizar los costos de desarrollo.  Garantizar un retorno de inversión.  Mejorar las condiciones de trabajo de los empleados. c. Madurez vs Inmadurez En esta sección a través de la siguiente tabla se muestra la comparación entre una organización madura y una inmadura: Tabla 6: Comparación de Madurez e Inmadurez Organizaciones con procesos Organizaciones con procesos inmaduros maduros Procesos improvisados por los Procesos documentados gerentes y desarrolladores. Cada uno posee sus propios procesos. Procesos seguidos consistentemente Procesos comprometidos en orden a El rendimiento de los procesos es cumplir los costos y las fechas medio, seguido y entendido. acordadas. Calidad difícil de predecir La calidad es predecible porque están bajo control. Los procesos “viven” mientras viven Los procesos “viven” por si solos y los desarrolladores. son mejorados continuamente. Las nuevas tecnologías corren riesgos Las nuevas tecnologías son de caer en desuso. incorporadas de una manera disciplinada. FUENTE: (Biagioli, Germana, 2009) 1.6.3. REPRESENTACIÓN Y NIVELES Las representaciones pueden ser de dos maneras:  Representación Continua.  Representación por Etapas Cabe destacar que para ayudar a aquellas organizaciones que se desempeñan en entornos ágiles a interpretar las prácticas de CMMI v1.3, se utiliza el componente mencionado arriba denominado “Notas” para especificar el uso de prácticas ágiles. a. Representación por Etapas La representación por etapas utiliza los niveles de madurez para caracterizar el estado global de los procesos de la organización con 19 respecto al modelo como un todo, los niveles de madurez se refieren a la consecución de las mejoras de proceso. Los cinco niveles de madurez se numeran del 1 al 5.  Nivel de madurez 1 Inicial: En el nivel de madurez 1, los procesos son generalmente ad hoc y caóticos, en estas organizaciones no proporción un estado estable su éxito depende de la competencia y heroicidad del personal de la organización.  Nivel de madurez 2 Gestionado: En el nivel de madurez 2, se garantiza que en los proyectos los procesos se planifican y ejecutan de acuerdo con las políticas; los proyectos emplean personal cualificado que dispone de recursos adecuados para producir resultados controlados; se involucran a todas las partes interesadas  Nivel de madurez 3 Definido: En el nivel de madurez 3, los procesos están bien caracterizados y comprendidos, y se describen en estándares, procedimientos, herramientas y métodos, los procesos se establecen y se mejoran a lo largo del tiempo.  Nivel de madurez 4: Gestionado cuantitativamente En el nivel de madurez 4, la organización y los proyectos establecen objetivos cuantitativos para la calidad y el rendimiento del proceso, y los utilizan como criterios en la gestión de los proyectos. Los objetivos cuantitativos se basan en las necesidades del cliente, usuarios finales, organización e implementadores del proceso. La calidad y el rendimiento del proceso se interpretan en términos estadísticos y se gestionan durante la vida de los proyectos.  Nivel de madurez 5 Optimización: En el nivel de madurez 5, una organización mejora continuamente sus procesos basándose en las necesidades de rendimiento se centra en mejorar continuamente el rendimiento de los procesos mediante mejoras incrementales e innovadoras de proceso y de tecnología. 20 Figura 4: Representación por Etapas Tabla 7:Categoría y Nivel Categoría/ Nivel 2 Nivel 3 Nivel 4 Nivel 5 Nivel Definición de Rendimiento Gestión del Procesos de de Procesos Rendimient la de la o de la Organización Organización Organizaci (OPD) (OPP) ón (OPM) Gestión de Enfoque en Procesos proceso de la organización (OPF) Formación Organizaciona l (OT) Administraci Gestión de Gestión ón de Riesgos Cuantitativa Acuerdos (RSKM) del Proyecto con (QPM) Proveedores (SAM) Gestión de Gestión de Gestión Proyectos Requerimien integrada de tos (REQM) proyectos (IPM) Monitoreo y Control de Proyecto (PMC) 21 … continuación Planificación del Proyecto (PP) Desarrollo de Requisitos (RD) Solución Ingeniería Técnica(TS) Validación (VAL) Integración del Producto (PI) Gestión de Análisis de Análisis y Configuració decisiones y Re-solución n (CM) resolución de Causas (DAR) (CAR) Aseguramien Soporte to de Calidad de Procesos y Productos (PPAQ) Medición y Análisis (MA) FUENTE: CMMI para desarrollo, versión 1.3 1.6.4.ÁREAS DE PROCESO EN CMMI V1.3 Las áreas de proceso se ven de forma diferente entre las dos representaciones existentes (continua y por etapas). La representación continua permite a la organización elegir el enfoque de sus esfuerzos de mejora de procesos mediante la elección de aquellas áreas de proceso, o conjuntos de áreas de proceso interrelacionadas, que benefician más a la organización y a sus objetivos de negocio. En cambio, la representación por etapas anima a ver siempre áreas de proceso en el contexto del nivel de madurez al cual pertenecen. Las áreas de proceso se organizan en niveles de madurez para reforzar este concepto. En esta tesis tomaremos las área de proceso de Validación (VAL) y verificación (VER). a. VALIDACIÓN (VAL) Demostrar que un producto o componente de producto se ajusta a su uso previsto cuando se sitúa en su entorno previsto.Las actividades de validación se pueden aplicar a todos los aspectos del producto en cualquiera de sus entornos previstos, tales como operación, formación, fabricación, mantenimiento y servicios de soporte. 22 Metas y prácticas específicas  SG1 Preparar la validación. o SP 1.1 Seleccionar los productos para la validación. o SP 1.2 Establecer el entorno de validación. o SP 1.3 Establecer los procedimientos y los criterios de validación.  SG 2 Validar el producto o los componentes de producto. o SP 2.1 Realizar la validación. o SP 2.2 Analizar los resultados de la validación b. VERIFICACIÓN (VER) Asegurar que los productos de trabajo seleccionados cumplen sus requerimientos especificados. El área de proceso Verificación implica lo siguiente: preparación de la verificación, realización de la verificación e identificación de acciones correctivas. Metas y prácticas específicas  SG 1 Preparar la verificación. o SP 1.1 Seleccionar los productos de trabajo para la verificación. o SP 1.2 Establecer el entorno de verificación. o SP 1.3 Establecer los procedimientos y los criterios de verificación.  SG 2 Realizar las revisiones entre pares. o SP 2.1 Preparar las revisiones entre pares. o SP 2.2 Realizar las revisiones entre pares. o SP 2.3 Analizar los datos de las revisiones entre pares.  SG 3 Verificar los productos de trabajo seleccionados. o SP 3.1 Realizar la verificación. o SP 3.2 Analizar los resultados de la verificación 1.6.5. INTERPRETAR CMMI V1.3 PARA LA UTILIZACIÓN DE METODOLOGÍAS ÁGILES Para ayudar a entender a quienes utilizan métodos ágiles a interpretar prácticas de CMMI en sus ambientes de trabajo, se han incluido notas explicativas en esta versión de CMMI para las áreas de proceso de estudio en esta tesis. Estas notas se muestran usualmente en las notas introductorias de las siguientes áreas de proceso:  Validación (VAL)  Verificación (VER). Todas estas notas comienzan con las palabras, “En ambientes ágiles” 15 y están en cajas de ejemplo para ayudar a reconocerlos fácilmente y que sirvan de recordatorio de que dichas notas son ejemplos de cómo interpretar esas prácticas. Sin embargo, los ejemplos de dichas prácticas no son suficientes para satisfacer el área de proceso correspondiente. 23 En la Tabla se detallan las notas para ambientes ágiles en las áreas de proceso de CMMI v1.3. Tabla 8: Notas para ambientes agiles en las áreas de proceso de CMMI v1.3 Área de Interpretación para ambientes ágiles proceso Validación (VAL)  En entornos ágiles, los equipos tienden a enfocarse en necesidades inmediatas en vez de necesidades a largo plazo.  Para asegurarse que las evaluaciones objetivas tienen valor y son eficientes, se debe discutir lo siguiente de forma temprana: ¿Qué tan objetivas deben ser las evaluaciones a ser realizadas?, ¿Qué productos de trabajo o procesos serán evaluados?, ¿Cómo los resultados de las evaluaciones serán integrados al ritmo del equipo? Verificación  En entornos ágiles, debido a las constantes (VER) entregas e involucramiento del cliente, la verificación y la validación van de la mano. Por ejemplo, un defecto puede causar que un prototipo o entrega temprana falle la validación de forma prematura.  De la misma forma, la continua y temprana validación ayuda a asegurar que la verificación se está haciendo sobre el producto correcto. FUENTE: Elaboración propia 1.7. EMPRESA 1.7.1. DEFINICIÓN DE EMPRESA OFISIS Consultora peruana de sistemas con certificación internacional de calidad CMMI, especialista en la consultoría, implementación y desarrollo de sistemas de información empresarial a fin de volverlas más productivas y competitivas. Su conocimiento de la realidad local y regional los compromete a brindar el soporte técnico, funcional y legal que el mercado exige. Es por eso que sus productos y servicios están respaldados por su trayectoria de éxito con empresas que hoy nos ven como su socio estratégico. OFISIS es una empresa con responsabilidad social que promueve diferentes iniciativas como el concurso universitario, premio OFISIS a la innovación en software. 24 1.7.2. DEPARTAMENTOS a. DEPARTAMENTO DE CONSULTORÍA Conformada por un grupo de consultores expertos que tienen como objetivo captar, analizar y establecer los requerimientos de los clientes, brindándole óptimas soluciones logrando así cumplir con la necesidad del cliente permitiendo incrementar su productividad y rentabilidad de negocio. b. DEPARTAMENTO DE CALIDAD Este departamento tiene como finalidad realizar una serie de actividades coordinadas que se realizan sobre un conjunto de elementos (Recursos, Procedimientos, Documentos, Estructura organizacional y Estrategias) para lograr la calidad de los productos que se ofrecen al cliente, es decir, planear, controlar y mejorar aquellos elementos de una organización que influyen en la satisfacción del cliente y en el logro de los resultados deseados por la organización. c. DEPARTAMENTO DE DESARROLLO Departamento que busca el brindar la mejor solución al requerimiento definido con el cliente. Está formado por grupo de profesionales con amplia experiencia de herramientas de desarrollo y Bases de Datos, para crear Soluciones Óptimas, prácticas e innovadoras utilizando la tecnología más vanguardista adecuándonos a la necesidad de cada cliente y proyecto. 1.7.3. NORMAS GENERALES En OFISIS Consultoría peruana que trabaja para ofrecer productos y servicios de software de gestión a las empresas latinoamericanas, sin importar su tamaño o rubro, ayudando a que sus negocios sean más eficientes, competitivos y rentables, generando valor para los empleados, accionistas y la sociedad. OFISIS juega un papel fundamental en el desarrollo de las actividades de los clientes, ayudando a simplificar los procesos y agilizando la toma de decisiones; en definitiva, a que les aporten beneficios tangibles. En ese sentido, encontrará en OFISIS el aliado estratégico perfecto. Por eso, nuestros productos y servicios están concebidos para ser fáciles de usar e incorporan todas las funcionalidades necesarias para ofrecer los mejores resultados a las diferentes áreas de negocio, y para poder crecer en función de las necesidades que vayan surgiendo. 25 1.7.4. SITUACION ACTUAL La situación actual de la consultora de sistemas OFISIS genera que el área de consultoría devuelva los desarrollos al área de calidad por que no se realizaron las validaciones correspondientes del desarrollo en cuestión, provocando que se supere el tiempo de entrega planificada al cliente, y por ende invirtiendo más recursos de lo planificado originando una propuesta no rentable para la empresa e insatisfacción del cliente. A continuación en la siguiente figura se muestra las horas de garantías que ha asumido OFISIS en los últimos años. Horas de Garantia Mensual 800.00 600.00 400.00 200.00 0.00 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 2014 273.75 368.00293.00 264.00 248.50 316.00 174.50338.50 275.50 367.75 638.00 496.00 2015 539.50 695.50589.25 341.25 518.75 649.00 444.25389.25 545.20 594.10 616.30 Figura 5: Comparativo de Horas de Garantías de los años 2014-2015 Es importante mencionar que a partir del mes de noviembre del año 2014 la estructura organizacional de OFISIS cambio debido a la incorporación a la corporación extranjera SOFTLAND, lo cual se ve reflejado la carencia de un procedimiento de control de calidad. 1.8. HIPÓTESIS La hipótesis de esta investigación es si se logra desarrollar un procedimiento adecuado de control de calidad en la consultora de sistemas OFISIS, se podría optimizar los procesos de tiempos de entrega de los desarrollos, validación y verificación de los mismos. 1.8.1. HIPÓTESIS NULA: Si se logra desarrollar un procedimiento adecuado de control de calidad en la Consulta de Sistemas OFISIS, no se podría optimizar los procesos de 26 Horas tiempos de entrega de los desarrollos, validación y verificación de los mismos. 1.8.2. HIPÓTESIS SECUNDARIAS:  La investigación de los marcos de referencia del CMMI v1.3 y metodología ágil nos permitirán aplicar las mejores prácticas para el control de calidad.  La aplicación de la integración de la metodología CMMI y Ágil de control de calidad reducirá en un 25% las garantías del producto.  La aplicación de la metodología de control de calidad en las áreas de proceso del departamento de calidad mantendrá un alto nivel de satisfacción del cliente al entregar un producto de calidad y en el tiempo planificado. 27 CAPITULO II - MATERIAL Y MÉTODOS 28 2.1. MATERIALES 2.1.1. PRESENTA RELACIÓN DE PERSONAL, MATERIALES Y MEDIOS 2.1.1.1. POBLACIÓN Y MUESTRA a. POBLACIÓN La investigación se realizó tomando como población de estudio, al personal de calidad y a los departamentos que interactúan con este departamento, que labora en la empresa Consultora de Sistemas OFISIS. Son un total de 39 personas. La población está distribuida de la siguiente forma. Tabla 9: Población de estudio Nro. Área Personas Consultoría 20 Calidad 4 Desarrollo 15 Total 39 FUENTE: Elaboración Propia b. MUESTRA Se tomó como muestra un total 25 personas, las cuales se distribuyen de la siguiente manera: Tabla 10: Muestra del estudio Nro. Área Personas Consultoría 12 Calidad 3 Desarrollo 10 Total 25 FUENTE: Elaboración Propia 2.1.1.2. TÉCNICAS DE RECOLECCIÓN DE DATOS a. ENCUESTAS Se realizaron al personal de la empresa, y permitió obtener información mediante preguntas atreves de las cuales se obtuvieron respuestas en forma escrita y virtual que ampliaron la información y sustentaron la investigación en estudio. 29 b. ENTREVISTA La entrevista se utilizó para profundizar en la búsqueda de la información sobre el tema en estudio, mediante preguntas específicas realizadas al gerente del departamento de consultoría. c. OBSERVACIÓN DIRECTA Mediante esta técnica, se realizaron visitas a cada una de las áreas involucradas de la empresa. Lo que nos permitió observar los procedimientos que utilizan en relación al control de la calidad, el seguimiento de los desarrollos. 2.1.2. TIEMPO, EQUIPAMIENTO, SITUACIÓN Y EXIGENCIAS DEL PROBLEMA 2.1.2.1. TIEMPO Las actividades de la investigación se han planificado de la siguiente manera que podamos concluir tanto con el proceso investigación como con la finalización de la presente tesis. Tabla 11: Cronograma de la investigación 2015 ACTIVIDADES SET OCT NOV DIC PLANEAMIENTO DE LA INVESTIGACIÓN Identificación problemática y exploración de X la realidad Presentación y Revisión del proyecto por el X asesor Revisión de los jurados y Levantamiento de X Observaciones Aprobación del Proyecto X EJECUCIÓN DEL PROYECTO Coordinar y Aprobación X Proceso de Ejecución Instrumental, X codificación y recolectar información Procesar datos con el e-encuesta X Análisis de resultados X Consulta a Tutor, Asesor y Estadístico X ELABORAR Y ENTREGA DE INFORME ESPECIALIZACIÓN Redacción del informe de tesis de X X X especialización Revisión asesor X X X 30 … continuación Presentar Informe de tesis X X Revisión del jurado de tesis X X Levantamiento de Observaciones X X Aprobación de la tesis de especialización X Sustentación y/o publicación X FUENTE: Elaboración Propia 2.1.2.2. EQUIPAMIENTO a. EQUIPAMIENTO DE INFRAESTRUCTURA Los equipos que se requieren para la presente tesis deben ser y cumplir con las siguientes características: Tabla 12 – Equipamiento de Infraestructura Equipos Descripción Cantidad Uso Laptop Intel® Core I5 1.70 GHz, 1 Permanente 6GB de RAM, HDD 700GB Impresora HP Laser 2055 BN 1 Permanente Proyector Proyector Multimedia 1 A demanda HITACHI FUENTE: Elaboración Propia b. EQUIPAMIENTO DE DOCUMENTACIÓN El software que se requiere para la elaboración de la documentación deben ser los siguientes con sus versiones respectivas: Tabla 13: Equipamiento de Documentación Software Descripción Licencia Cantidad WINDOWS 7 Microsoft Microsoft 1 Ultimate. Versión SP 1 Ms Word Herramienta de Microsoft Microsoft 1 2013 Office que nos permite crear documentos de texto requeridos para la gestión y ejecución del proyecto y producto. Ms Excel Herramienta de Microsoft Microsoft 1 2013 Office que nos permite crear hojas de cálculo, para la elaboración de la gestión del proyecto. 31 … continuación Ms Power Herramienta de Microsoft Microsoft 1 Point 2013 Office que nos permite crear las presentaciones (Como los avances y entre otros) realizadas en toda la ejecución del proyecto. FUENTE: Elaboración Propia c. EQUIPAMIENTO DE MODELAMIENTO Las herramientas que se utilizaron en la presente tesis para la elaboración de los procesos son: Tabla 14: Equipamiento de Modelamiento Software Descripción Licencia Cantidad BIZAGI Es un Freeware utilizado Software 1 Process para diagramar, documentar Libre Modeler. y simular procesos usando Versión: 2.8.0.8 la notación estándar BPM., que se utilizó para mostrar el procedimiento de atención de requerimientos. FUENTE: Elaboración Propia d. EQUIPAMIENTO DE COMUNICACIÓN Las herramientas que se utilizaron en la presente tesis para la comunicación son: Tabla 15: Equipamiento de Comunicación Software Descripción Versión Gmail Utilizaremos Gmail para la comunicación Libre con Correos electrónico. Google Herramienta para compartir información en Libre Drive línea y almacenamiento de datos en la nube. Skype Un software que permite comunicaciones Libre de texto, voz y vídeo sobre Internet. WhatsApp Un software que permite comunicaciones Libre de texto, voz y compartir archivo sobre Internet. FUENTE: Elaboración Propia e. EQUIPAMIENTO DE ENCUESTA La herramienta que se usaron en la presente tesis para la elaboración de encuestas son: 32 Tabla 16: Equipamiento de Encuesta Software Descripción Licencia E-encuesta Herramientas para la Software Libre elaboración de encuestas vía internet. FUENTE: Elaboración Propia Se llegó a establecer el siguiente costo por desarrollo del proyecto de tesis: Tabla 17: Costos de Recursos Humanos Costos de Recursos Humanos Recursos Humanos Cantidad Costo S/. Analista 1 3,500.00 Asesores 1 - Subtotal 3,500.00 FUENTE: Elaboración Propia Tabla 18: Costo de Equipos Costos de Equipos Equipos Cantidad Costo S/. Laptops 1 - Impresora 1 - Proyector 1 - Subtotal - FUENTE: Elaboración Propia Tabla 19: Costo de Software Costos de Software Software Cantidad Costo S/. Microsoft 2013 1 - Bizagi Process Modeler 1 - Gmail 1 - Google Drive 1 - Skype 1 - WhatsApp 1 - E-encuesta 1 - Subtotal - FUENTE: Elaboración Propia Tabla 20: Costo de Servicio Costos de Servicio Servicio Costo S/. Servicios Básicos(Luz y teléfono) 250.00 Internet 180.00 33 … continuación Movilidad 70.00 Impresiones 150.00 Anillados 20.00 Empastado 30.00 Subtotal 700.00 FUENTE: Elaboración Propia Tabla 21: Costo Total del Proyecto Costo Total del Proyecto Total Costo S/. Subtotal de proyecto 3,500.00 Subtotal de Bienes - Subtotal de Servicios 700.00 Total 4,200.00 FUENTE: Elaboración Propia 2.1.2.3. SITUACIÓN En la actualidad el área de calidad de la Consultora de Sistemas OFISIS no está llevando un adecuado control de calidad de los desarrollos entregados por TI, lo cual está generando problemas en los tiempos de entrega de los desarrollos, validación y verificación de los mismos. Por otro lado el área de consultoría al no plasmar todo el requerimiento del cliente detalladamente causa ambigüedades de los desarrollos a entregar. Esta situación genera a diario que el área de consultoría devuelva los desarrollos al área de calidad por que no se realizaron la validación de todas las casuísticas del desarrollo en cuestión, provocando que se supere el tiempo de entrega planificada al cliente, y por ende invirtiendo más recursos de lo planificado originando una propuesta no rentable para la empresa (un costo de inversión) e insatisfacción del cliente. 2.1.2.4. EXIGENCIA DEL PROBLEMA La exigencia del problema nos lleva a complementar la metodología CMMI, que actualmente cuenta la Consultora de Sistema OFISIS, con la metodología Ágil, permitiendo mejorar la eficiencia en la producción y la calidad de los productos finales, tener la capacidad de respuesta al cambio en los productos y sus definiciones, y brindar la mayor satisfacción posible al cliente, a través de la entrega temprana y la retroalimentación continua durante la construcción del producto. 34 2.2. MÉTODOS 2.2.1. PROCEDIMIENTOS O MÉTODOS Se han empleado los métodos deductivos, método observacional y el método estadístico. En esta tesis se utilizó el método deductivo para poder deducir los problemas partículas partiendo de los problemas generales. Con este método se pudo deducir que mayormente las garantías (errores) de los productos se acentúan cuando no se hace una validación continua de los desarrollos, ya que los jefes de los desarrolladores mayormente no revisan los desarrollos y si lo hacen, lo realizan al final del desarrollo, conllevando a que la probabilidad de encontrar garantías en el producto sea mayor. Se usó también el método observacional ya que se observó las conductas de los trabajadores de cada departamento indicados en la presente tesis. Así como también se observó que el tiempo que le dedican a los desarrollos y validación. Y finalmente se observó las condiciones en las que trabajan. Y por último se utilizó el método estadístico ya que de acuerdo a las encuestas y entrevista realizadas a los colaboradores de cada departamento involucrado (consultoría, calidad y desarrollo) se pudo obtener resultados que nos permiten medir la situación actual de cada departamento, poniendo a relucir sus fortalezas y debilidades. 2.2.2. DISEÑO DE INVESTIGACIÓN a. VARIABLES  Propuesta de Investigación.  Área de proceso de Validación y Verificación del CMMI V1.3.  Metodología Agiles. b. DEFINICIÓN OPERACIONAL DE LAS VARIABLES Tabla 22: Definición operacional de variables Variables Definición Conceptual Definición operacional Indicadores Propuesta de La propuesta de Con la propuesta de Reducción en las Investigación investigación es producto investigación se busca poder garantías del de un proceso de trabajo identificar, monitorear, producto que incluye varias controlar y minimizar la Reducción del actividades importantes, probabilidad de ocurrencia de tiempo de espera de las cuales depende su garantías del producto, así por producto éxito o fracaso. como también su entrega Base de temprana del producto, y conocimientos de dejar en evidencia que existe errores una estrategia de validación y verificación institucionalizada dentro de la organización. 35 … continuación Área de El área de proceso de Las prácticas de VAL Cantidad de proceso de Validación (VAL) tiene demuestran que el producto productos que Validación y como propósito generado pueda ser utilizado. funcionan sin Verificación del demostrar que un garantías en su CMMI V1.3 producto o componente Las prácticas de VER entorno. de producto se ajusta a permiten identificar defectos Cantidad de su uso previsto cuando en etapas tempranas de la productos que se sitúa en su entorno creación del producto y cumplen con sus previsto. reducir los altos costos requerimientos El área de proceso de asociados a la identificación y específicos. Verificación (VER) tiene corrección de defectos que se Reducción de como propósito asegurar pueden presentar más costos de que los productos de adelante. corrección de trabajo seleccionados defectos cumplen sus requerimientos especificados Metodología La Metodología Ágil Con la metodología Ágil se Entrega de Agiles plantea permitir mejorar busca trabajar con iteraciones Objetivos y la eficiencia en la ya que se ha comprobado que velocidad producción y la calidad de es realmente productivo ya los productos finales, que el cliente puede probar el Horas pendientes tener la capacidad de sistema y es cuando nuevos de iteración. respuesta al cambio en defectos o la mala los productos y sus interpretación que pudo existir definiciones, y brindar la de algún requerimiento se mayor satisfacción manifiesta y es visible para el Porcentaje de posible al cliente, a través trabajo, lo que permite tomar Defectos de la entrega temprana y acción rápidamente y no la retroalimentación esperar hasta la entrega de continua durante la un producto final, donde el construcción del costo de corregir errores se producto. incrementa considerablemente. FUENTE: Elaboración Propia 2.2.3. TIPO DE INVESTIGACIÓN La presente investigación se enmarco en los tipos de investigación: No experimental, descriptiva y Explicativa. a. DESCRIPTIVA Es descriptiva porque, se describió la situación actual de los procesos de validación y entrega del software en OFISIS. 36 b. EXPLICATIVA La información obtenida mediante la descripción de la situación actual de los procesos de validación y entrega se analizó para llevar a cabo la propuesta de investigación y para obtener conclusiones y recomendaciones. 2.2.4. ENFOQUE DE INVESTIGACIÓN El enfoque de la investigación será mixto, cualitativo y cuantitativo: Cuantitativo porque se realizó la recolección de datos mediante las encuestas realizadas a los colaboradores de cada departamento obteniendo indicadores numéricos que nos permiten probar la hipótesis de que si se logra desarrollar un procedimiento adecuado de control de calidad en la consultora de sistemas OFISIS, se podría optimizar los procesos de tiempos de entrega de los desarrollos, validación y verificación de los mismos. Cualitativo porque se realizó entrevistas al gerente del departamento de consultoría, en la cual nos proporcionó información relevante en cuanto el comportamiento humano de las personas que trabajan en el departamento de calidad, en la cual precisó que las prioridades de este departamento eran distintos a los de su departamento. 2.2.5. DELIMITACIÓN Y DEFINICIÓN DE LA POBLACIÓN DE ESTUDIO La tesis en estudio se realizó en la consultora de sistemas OFISIS, en los departamentos de consultoría, calidad y desarrollo. 2.2.6. APLICAR CRITERIOS PARA SELECCIONAR MUESTRA DE ESTUDIO a. MUESTRA PROBABILÍSTICA ESTRATIFICADA La estratificación aumenta la precisión de la muestra e implica el uso deliberado de diferentes tamaños de muestra para cada estrato, “a fin de lograr reducir la varianza de cada unidad de la media muestral” (Kish, 1965). Dice Kish (p. 92) en su libro de muestreo que en un número determinado de elementos muéstrales n = Z n h la varianza de la media muestral 7 puede reducirse al mínimo si el tamaño de la muestra para cada estrato es proporcional a la desviación estándar dentro del estrato. Esto es, 37 En donde fh es la fracción del estrato, n el tamaño de la muestra, N el tamaño de la población, sh es la desviación estándar de cada elemento en el estrato h, y K es una proporción constante que nos dará como resultado una q óptima para cada estrato. 2.2.7. CRITERIOS DE INCLUSIÓN Y EXCLUSIÓN a. CRITERIOS DE INCLUSIÓN  Entregables que tuvieron más de 2 iteraciones con el área de Desarrollo.  Entregables que no pasaron por el área de Calidad y generaron garantía.  Entregables devueltos por Consultoría y/o cliente  Entregables que no cumplieron con la necesidad del cliente.  Entregables que no fueron documentados sus pruebas.  Entregables que fueron devueltos al ares de Desarrollo y que no fueron documentados las observaciones halladas. b. CRITERIOS DE EXCLUSIÓN  Entregables que no generaron garantía.  Entregables que fueron documentados bajo una metodología y que tuvieron una validación exitosa por parte del área de Consultoría.  Tener entregables validados satisfactoriamente con el área de Consultoría con los recursos y en el tiempo planificado de acuerdo a la propuesta. 2.2.8. ANÁLISIS ESTADÍSTICO De acuerdo a la muestra probabilística estratificada tenemos que la población es de 39trabajadores en total de las áreas involucradas y que el tamaño de muestra es n = 25. La fracción para cada estrato fh será: fh= n / N = 25 / 39= 0.6410 De manera que el total de la subpoblación se multiplicará por esta fracción constante a fin de obtener el tamaño de muestra para el estrato. Sustituyendo tenemos que: Nh x fh = nh 38 Tabla 23: Análisis Estadístico Estrato por Trabajadores generales Total de Muestra departamento por departamento población* (fn) = 0.6410 Nh(fn) = nh 1 Consultoría 20 13 2 Calidad 4 3 3 Desarrollo 15 10 N = 39 n = 25 Por Ejemplo: Nh = 15 trabajadores extractivas corresponde a la población total de este departamento. Fh = 0.6410 es la fracción constante. Nh = 10 es el numero redondeado del departamento extractivo que tendrán que entrevistarse. FUENTE: Elaboración Propia 39 CAPITULO III - RESULTADOS 40 3.1. REPRESENTACIÓN E INTERPRETACIÓN DE RESULTADOS Para poder determinar y establecer el estímulo para la mejora se desarrolló las siguientes actividades: 3.1.1. ENTREVISTA AL AREA DE CONSULTORIA Se entrevistó al Gerente de Consultoría y se realizó las encuestas a 13 analistas del área de consultoría. De las encuestas se obtuvo los siguientes resultados: a. Pregunta 1:¿Si tuvieras que calificar la calidad del desarrollo entregado, como lo calificarías? Objetivo: Conocer la satisfacción de los encuestados con respecto a la calidad de los desarrollos entregados. Figura 6: Respuesta pregunta 1 de consultoría Interpretación: El 61.54% de la población encuestada considera que la calidad de los desarrollos entregados son regulares ya que muestran errores de programación, el 23.08% opinaron que si tiene un buen control de calidad los desarrollos, el 7.69% opinaron que el control de calidad es excelente, mientras el 7.69% indico que la calidad del desarrollo es malo. Los desarrollos entregados a consultoría no están validados correctamente y en muchos de ellos no cumplen con lo indicado en el requerimiento del cliente, ya que no reciben una revisión iterativa en la etapa del desarrollo. 41 b. Pregunta 2:¿Se realiza la entrega de los desarrollos de acuerdo a los tiempos planificados? Objetivo: Conocer si los desarrollos son entregados en el tiempo planificado. Figura 7: Respuesta pregunta 2 de consultoría Interpretación: El 84.62% de la población encuestada considera que la entrega de los desarrollos no son entregados en la fecha planificada, ya que existen diferencias entre lo planificado vs lo entregado, mientras el 15.38% restante opinaron que si entregan el desarrollo a tiempo. Los desarrollos no son entregados en las fechas planificadas debido a que la revisión la realizan al finalizar los desarrollos y en muchas ocasiones encuentra observaciones a corregir y esto hace que se devuelva el producto al programador para que lo corrija, conllevando a que no se cumpla con la fecha planificada. c. Pregunta 3: Cuándo se tiene observaciones en el proceso de validación con el usuario, ¿se documenta estas observaciones y a que área se informa? Objetivo: Conocer si se documentan las observaciones y si tienen un procedimiento estandarizado de reportar las observaciones. 42 Figura 8: Respuesta pregunta 3 de consultoría Interpretación: El 76.92% de la población encuestada indica que las observaciones encontradas las reportan vía mail y las entregan al área de desarrollo, mientras el 15.38% reporta las observaciones vía mail y las entrega al área de calidad, y solamente el 7.69% utiliza el registro de incidencias para reportar el caso. Las observaciones no son documentados correctamente, ya que solo lo describen en el correo y no colocándolo en formato especial para levantar observaciones. Así mismo, no tienen claro a que canal deben de reportar estas observaciones, ya que una parte lo deriva a desarrollo, mientras la mayoría lo reporta al área de calidad. d. Pregunta 4: En caso los desarrollos vayan a tener una demora en la entrega, ¿se informa al cliente oportunamente? Objetivo: Conocer si existe una comunicación directa con el cliente y este se encuentre informado de las variaciones que pueda tener lo desarrollado. Figura 9: Respuesta pregunta 4 de consultoría 43 Interpretación: El 69.23% de la población encuestada indica que informa al cliente oportunamente que existirá un retraso en la entrega del producto final, mientras el 30.77% restante indicaron que no informan oportunamente. Al no informar al cliente oportunamente sobre el retraso produce una sensación de desconfianza del cliente hacia la empresa, produciendo insatisfacción desde antes de lo entregado. e. Pregunta 5: Cuando se termina con la implementación de lo desarrollado en el cliente, ¿se realiza algún tipo de documentación? Objetivo: Conocer si existe documento de validación. Figura 10: Respuesta pregunta 5 de consultoría Interpretación: El 84.62% de la población encuestada indica que si realiza un documento de validación con el cliente, mientras un 15.38% restante indica que no lo hace. Esta documentación consiste en un formato de validación de los entregables, en donde el cliente confirma, mediante firma, que esta validado el producto y conforme, esto es en el mejor de los casos; en caso el entregable tuviera errores el cliente no firma tal documento de validación y el analista reporta el error vía correo al departamento de desarrollo. 3.1.2. ENTREVISTA AL AREA DE CALIDAD Se entrevistó al Gerente de Calidad y se realizó las encuestas a 3 analistas del área de calidad. De las encuestas se obtuvo los siguientes resultados: 44 a. Pregunta 1: ¿Realizan reuniones de áreas semanales para revisar lo ejecutado vs lo planificado? Objetivo: Saber si existe un control o seguimiento a los trabajos asignados en el área de Calidad, y si cumplen con la práctica específica 2.1 del CMMI v1.3 de verificación, que es la preparación de la revisión entre pares (SP 2.1). Figura 11: Respuesta pregunta 1 de calidad Interpretación: El66.67% de la población encuestada indica que no realiza reuniones semanales para revisar lo ejecutado vs lo planificado, mientras el 33.33% restante indica que si lo hace. Eventualmente el área de calidad tiene reuniones en donde revisan que el trabajo en ejecución se alinee al planificado. b. Pregunta 2: ¿Cuándo se realiza la validación y verificación del desarrollo en que documento se apoya? Objetivo: Conocer si el personal del Área de Calidad utiliza algún tipo de documento para los procesos de validación y verificación. Y si cumple con las siguientes prácticas específicas CMMI v1.3:  Validación: Seleccionar los productos a validar (SP 1.1).  Verificación: Seleccionar los productos de trabajo a verificar (SP 1.1). 45 Figura 12: Respuesta pregunta 2 de calidad Interpretación: Como se puede apreciar en la figura el 66.67% indica que se apoya en la documentación funcional (documento entregado por consultoría al área de calidad) y técnico (documento entregado por calidad al área de desarrollo). c. Pregunta 3: ¿Se cuenta con el ambiente necesario para realizar la validación y verificación de los desarrollos? Objetivo: Conocer si el personal del Área de Calidad cuenta con el ambiente adecuado para poder realizar la validaciones y verificación de los desarrollos a entregar. Y si cumple con las siguientes prácticas específicas del CMMI v1.3:  Validación: Establecer el entorno de validación (SP 1.2).  Verificación: Establecer el entorno de verificación (SP 1.2). Figura 13: Respuesta pregunta 3 de calidad 46 Interpretación: Como se puede apreciar en la figura el 100% de la población encuestada indica que NO cuentan con el ambiente necesario para realizar la validación y verificación de los desarrollos. d. Pregunta 4: ¿Se establece criterios y procedimientos para la validación y verificación de los desarrollos? Objetivo: Conocer si cumple con las prácticas específicas del CMMI v1.3 siguientes:  Validación: Establecer los procedimientos y los criterios de validación (SP 1.3).  Verificación: Establecer los procedimientos y los criterios de verificación (SP 1.3). Figura 14: Respuesta pregunta 4 de calidad Interpretación: El 66.67% de la población encuestada indica que no se establece criterios y procedimientos de validación y verificación de los desarrollos, mientras el 33.33% indica que sí. Es importante precisar que estos procedimientos lo realizan al finalizar los desarrollos y no existe un procedimiento de validación que se realice durante el desarrollo. e. Pregunta 5: ¿Los resultados de la validación y verificación, son debidamente documentados? Objetivo: Saber si cumple con las prácticas específicas del CMMI v1.3 siguientes:  Validación: Realizar la validación (SP 2.1).  Verificación: Realizar la verificación (SP 3.1).  Verificación: Analizar los resultados de la verificación (SP 3.2). 47 Figura 15: Respuesta pregunta 5 de calidad Interpretación: Como se puede apreciar en la figura el área de calidad confirma que Nunca documentan los resultados de los procesos de validación y verificación de los desarrollos validados y entregados al área de Consultoría. f. Pregunta 6: ¿Se realiza un proceso de análisis de los resultados de la validación y verificación para medidas correctivas? Objetivo: Saber si cumple con la siguiente práctica específica del CMMI v1.3:  Validación: Analizar los resultados de la validación (SP 2.2).  Verificación: Analizar los resultados de la verificación (SP 3.2). Figura 16: Respuesta pregunta 6 de desarrollo Interpretación: Como se puede apreciar en la figura la mayoría de la población de la muestra, no realiza el análisis de los resultados para poder realizar correcciones a los futuros desarrollos. 48 3.1.3. ENTREVISTA AL AREA DE DESARROLLO Se realizó las encuestas a 10 programadores del área de desarrollo. De las encuestas se obtuvo los siguientes resultados: a. Pregunta 1: ¿Usted, actualmente cuenta con trabajo planificado? Objetivo: saber si el personal del Área de Desarrollo tiene sus tareas planificadas. Figura 17: Respuesta pregunta 1 de desarrollo Interpretación: Como se puede apreciar en la figura el total de la población de programadores encuestados indica que cuenta con trabajo programado. b. Pregunta 2: En cuanto a los errores presentados en el desarrollo de un producto, ¿Qué tipo de errores ha tenido usualmente? Objetivo: Saber cuáles son los tipos de errores que habitualmente tiene el personal de Desarrollo. A la vez confirmar si cumple con la práctica específica de verificación “Analizar los datos de la revisión entre pares” (SP 2.3) del CMMI v1.3. 49 Figura 18: Respuesta pregunta 2 de desarrollo Interpretación: Como se puede apreciar en la figura el 80% de la población encuestada indica que los errores más comunes se deben a que no se tiene muy claro el requerimiento solicitado por el cliente, y esto se debe a dos factores: que el alcance de requerimiento del cliente no se encuentra claro o que el programador interpretó de otra forma el alcance de requerimiento, generando atrasos en la entrega de los desarrollos. c. Pregunta 3: ¿Se realiza supervisión de los desarrollos asignados? Objetivo: Conocer si cumplen con la práctica específica del CMMI v1.3 siguiente: Verificación: Llevar a cabo las revisiones entre pares (SP 2.2). Figura 19: Respuesta pregunta 3 de desarrollo Interpretación: El 80% indica que nunca realizan supervisión de los desarrollos, mientras el 20% indica que lo realizan eventualmente. La supervisión es al finalizar el desarrollo y en esta etapa el riesgo de encontrar errores es mayor, y por ende las entregas de los trabajos lo realizan después de la fecha planificada. 50 d. Pregunta 4: ¿Se realiza documentación detallada de lo desarrollado y/o correcciones? Objetivo: Conocer si se cuenta con una base de conocimientos. Figura 20: Respuesta pregunta 4 de desarrollo Interpretación: Como se puede apreciar en la figura el 70% indica que si realiza documentación de los desarrollos y correcciones, esto es bueno ya que a partir de ello se puede realizar una base de conocimientos más amplia. Sin embargo existe un 30% que indica que no realiza tal documentación. e. Pregunta 5: ¿Cuándo se da por terminado un desarrollo, se hace entrega de alguna documentación sobre este proceso? Objetivo: Dar a conocer si se realiza documentación una vez terminado el desarrollo. Figura 21: Respuesta pregunta 5 de desarrollo 51 Interpretación: Como se puede apreciar en la figura el 80% indica que entrega documentación con respecto al producto desarrollado, esto es bueno ya que a partir de ello se puede tener evidencia de lo desarrollado para futuras modificaciones al producto. Sin embargo un 20% indica que no entrega documentación alguna. 3.2. DETERMINACIÓN DE LA MADUREZ DE LA ORGANIZACIÓN Se determinó el grado de madurez actual de la organización. Para determinar el análisis de brechas se dividió en base a las áreas de procesos a desarrollar en el modelo propuesto. Para realizar el diagnóstico se tomó en cuenta la siguiente fórmula: El rango de porcentaje para cada estado se calculó en base a la siguiente fórmula: X (%) porcentaje para cada meta específica = (100% / # SG.). Y (%) porcentaje para cada práctica específica = (X% / # SP.). SG= Meta Específica SP= Prácticas Específica Para alcanzar el 100% de cumplimiento de la meta específica de las áreas de proceso de validación y verificación, se estableció que cada meta específica alcanza X% del total, para las practicas especificas alcanza Y% del total de X%. De tal manera se tomó como referencias para establecer los rangos para los estados por cada área de proceso. Para alcanzar el 100% de cumplimiento en base a las 2 áreas de procesos en estudio, se estableció que cada área de proceso deberá alcanzar un 50% del total de prácticas específicas que contiene. De tal manera se tomó como referencias para establecer los rangos para los estados. Tabla 24: Rango de estados FUENTE: Elaboración Propia 52 3.2.1. DIAGNÓSTICO DE LA VALIDACIÓN A continuación se muestra el nivel de cumplimiento del Área de Proceso de Validación. Tabla 25: Metas y Prácticas específicas de Validación Validación (VAL) Metas y prácticas específicas Porcentaje (%) SG 1 Preparar la validación SP 1.1 Seleccionar los productos a validar 16.66 SP 1.2 Establecer el entorno de validación - SP 1.3 Establecer los procedimientos y los criterios de validación 5.56 SG 2 Validar el producto o los componentes de producto SP 2.1 Realizar la validación - SP 2.2 Analizar los resultados de la validación 8.33 Resultado 30.55 FUENTE: Elaboración Propia Diagnóstico: De los resultados obtenidos del cuestionario realizado se obtuvo que esta área de proceso de validación, se encuentre en un estado limitadamente cubierto con un porcentaje de 30.55% según las prácticas específicas requeridas por CMMI. 3.2.2. DIAGNÓSTICO DE LA VERIFICACIÓN A continuación se muestra el nivel de cumplimiento del Área de Proceso de Validación. Tabla 26: Mestas y Prácticas específicas de la verificación Verificación (VER) Metas y prácticas específicas Porcentaje (%) SG 1 Preparar la verificación SP 1.1 Seleccionar los productos de trabajo a verificar 11.11 SP 1.2 Establecer el entorno de verificación - 53 … continuación SP 1.3 Establecer los procedimientos y los criterios de verificación 3.70 SG 2 Realizar revisiones entre pares SP 2.1 Preparar las revisiones entre pares 3.70 SP 2.2 Llevar a cabo las revisiones entre pares 2.22 SP 2.3 Analizar los datos de la revisión entre pares 8.89 SG 3 Verificar los productos de trabajo seleccionados SP 3.1 Realizar la verificación - SP 3.2 Analizar los resultados de la verificación - Resultado 29.62 FUENTE: Elaboración Propia Diagnóstico: De los resultados obtenidos del cuestionario realizado se obtuvo que esta área de proceso de Verificación, se encuentra en un estado limitadamente cubierto con un porcentaje de 29.62% según las prácticas específicas requeridas por CMMI. 3.2.3. DIAGNÓSTICO GENERAL PARA DETERMINAR EL NIVEL DE MADUREZ DE LA ORGANIZACIÓN. Según lo establecido en con anterioridad se estableció que el porcentaje máximo para cumplir con la practicas especificas por cada área de proceso es del 50%; tomando en consideración este porcentaje se estableció la siguiente fórmula para el diagnóstico Global. Para determinar el diagnóstico global se realiza la siguiente manera: X (%) Diagnóstico Global = (% AP1 * 50%)+(% AP2 * 50%) AP1= Validación AP2= Verificación Los porcentajes de las áreas de procesos corresponde al que se generó en la parte de Diagnostico.  Validación (VAL) : 30.55%  Verificación (VER) : 29.62% 54 Como resultado se obtuvo que para la validación y verificación la organización se encuentra en un estado Limitadamente Cubierto con un 30.09% de prácticas específicas que se cumple en las 2 áreas de procesos. 3.3. PRESENTACIÓN DE LA PROPUESTA 3.3.1. DESCRIPCIÓN DE LA PROPUESTA PARA IMPLANTAR EL PROCESO DE VALIDACIÓN Y VERIFICACIÓN El proceso de validación y verificación propuesto a implantar está basado en las metas específicas (SG) del área de proceso de validación y verificación del CMMI v1.3: Validación:  Preparar la validación (SG 1)  Validar el producto o los componentes de producto (SG 2) Verificación:  Preparar la verificación (SG 1)  Realizar revisiones entre pares (SG 2)  Verificar los productos de trabajo seleccionados (SG 3) Cabe destacar así mismo que los artefactos propuestos para satisfacer cada una de las metas específicas y que se mencionan a continuación son contribución del autor de esta tesis. 3.3.2. PREPARAR LA VALIDACIÓN (SG 1) a. Seleccionar los productos a validar (SP 1.1) Los productos de trabajo a validar deberán ser seleccionados según las necesidades del cliente o usuario final, luego se establecen métodos o procedimientos de validación en base al grado de demostración de la satisfacción de las necesidades del usuario final. Para esta práctica nos apoyaremos en el documento de Alcance de Requerimiento en el cual se detalla funcionalmente el requerimiento hasta con el diseño de prototipos que fueron acordados con el cliente, adicionalmente también haremos uso y del alcance técnico en él se detalla los casos de uso. A continuación se muestra una estructura del alcance funcional. Mayor detalle de los alcances lo podrán revisar en la sección de Anexo N° 2. 55 Figura 22: Parte del Alcance Funcional En el caso que el consultor de calidad necesite absolver alguna duda del alcance funcional se coordinara una reunión con un consultor de consultoría para su aclaración. El área de Desarrollo hará entrega de un listado de los desarrollos a validar, el cual el jefe del área Calidad lo planificara para que el consultor de Calidad lo pueda realizar, esta planificación se hará uso en el control de tiempos como se muestra en la siguiente imagen. Figura 23: Pantalla de control de tiempos 56 b. Establecer el entorno de validación (SP 1.2) Esta práctica, establece el entorno de validación, que dependerá de los productos de trabajo seleccionados, este entorno debe considerar en lo posible el escenario esperado de ejecución del software. Para esta práctica haremos uso del documento de Alcance de Requerimiento en el cual se indica cual es el ambiente a utilizar para la validación de los desarrollos planificados. Figura 24: Parte del entorno de trabajo c. Establecer los procedimientos y los criterios de validación (SP 1.3) Una vez cumplidas las evidencias de las dos prácticas anteriores se establecen los procedimientos a usar en la validación, junto con los criterios que definen el ajuste a su uso previsto. Para esta práctica haremos uso del documento propuesto de Plan de Pruebas en el cual se detallan las opciones a validar. A continuación se muestra un fragmento del documento de Plan de Pruebas, que para su revisión se tendrá mayor detalle en el Anexo N° 9. 57 Figura 25: Parte del Plan de Pruebas Esta enumeración de opciones a validar deberán de cumplir de acuerdo a los Documentos estándares establecidos por la organización como son:  Estándares de nombres (Anexo N° 4)  Base de Datos (Anexo N° 5 Y N° 6)  Programas (Anexo N° 8)  Store Procedure (Anexo N° 7)  Reportes (Anexo N° 8)  También se debe de considerar los alcances funcionales (Anexo N° 10) 3.3.3. VALIDAR EL PRODUCTO O LOS COMPONENTES DE PRODUCTO (SG 2) a. Realizar la validación (SP 2.1) Esta práctica da como evidencia los resultados de la validación del producto o componentes de productos seleccionados, se genera un informe con los resultados de esta, se deben seguir los procedimientos que fueron establecidos. Para esta práctica se hará uso del documento del documento de Plan de Pruebas en el cual se colocara las opciones a validar y se marcara los estados de probado y aprobado según sea el caso de Validación. También se hará un seguimiento de la validación indicando quien realiza la validación, el tiempo invertido, fecha de término y si paso la validación. 58 b. Analizar los resultados de la validación (SP 2.2) En esta práctica se toman los resultados del proceso de validación y se usan los criterios de validación para establecer la aceptación del producto o la aproximación al resultado esperado, en caso de encontrar falencias notables, se realizan peticiones de cambio a los procesos de validación implicados y las respectivas acciones correctivas para los productos y componentes de producto validados. Para esta práctica se usa el documento de pruebas en el cual en cada opción se detallara en el caso de que encuentre alguna observación y que acciones correctivas se debe de realizar. En la siguiente imagen se muestra un ejemplo de cómo se deberá de llenar. Figura 26: Parte del documento de pruebas 3.3.4. PREPARAR LA VERIFICACIÓN (SG 1) El propósito de esta meta específica del área de proceso de verificación es elaborar un plan de verificación para la presente propuesta, el cual es asegurar que los productos de trabajo cumplan con los requisitos específicos. Esta meta específica requiere el cumplimiento de las siguientes prácticas específicas (SP):  Seleccionar los productos de trabajo a verificar (SP 1).  Establecer el entorno de verificación (SP 2).  Establecer los procedimientos y los criterios de verificación (SP 3). a. Seleccionar los productos de trabajo a verificar (SP 1.1) Los productos de trabajo candidatos para el proceso de verificación serán aquellos que tengan impacto en los requerimientos, los riesgos y objetivos del proyecto. 59 Para esta práctica la propuesta de la tesis se sustenta en hacer uso del alcance técnico en el cual se detallaran los casos de uso y casos de prueba, detallados para cada requerimiento. A continuación se muestra parte de la plantilla en donde se describe el alcance técnico y los casos de pruebas. En el anexo N° 10 se encuentra el formato total de la planilla del alcance técnico. Figura 27: Parte del documento Caso de uso b. Establecer el entorno de verificación (SP 1.2) El entorno de verificación tiene que ver con proporcionar las herramientas necesarias para realizar las pruebas de verificación a los productos de trabajo o código fuente para el caso de software, como evidencia se puede tener una documentación que describa que herramientas, lugar y software se utilizarán. Para la propuesta de esta tesis se debe de indicar en el alcance de requerimiento (alcance funcional) las especificaciones técnicas sobre el ambiente en el cual se va a realizar el desarrollo, validación y verificación del requerimiento. A continuación se muestra parte de la plantilla en donde se describe las herramientas, lugar y software. 60 Figura 28: Parte del Alcance de requerimiento c. Establecer los procedimientos y los criterios de verificación (SP 1.3) Los criterios de verificación buscan asegurar que los productos de trabajo cumplen con los requerimientos establecidos. En este punto se utilizara la documentación ya establecido en la organización sobre estándares de programación, listado de verificación de pares, alcance técnico y el alcance de requerimiento ya aprobado por el cliente. En los anexos a mencionar se encuentra la plantilla de los formatos a considerar para que cumplan con los criterios de verificación:  Estándares de Programación. Anexo N° 4, 5, 6, 7, 8  Lista de Verificación de pares. Anexo N° 12  Alcance Técnico. Anexo 13  Alcance de requerimiento (funcional). Anexo 3 3.3.5. REALIZAR REVISIONES ENTRE PARES (SG 2) Las revisiones entre pares implican un examen metódico de los productos de trabajo por los compañeros del mismo nivel que los autores con el fin de identificar defectos para su eliminación y de recomendar otros cambios que sean necesarios. Esta meta específica requiere el cumplimiento de las siguientes prácticas específicas (SP): 61  Preparar las revisiones entre pares (SP 1).  Llevar a cabo las revisiones entre pares (SP 2).  Analizar los datos de la revisión entre pares (SP 3). a. Preparar las revisiones entre pares (SP 2.1) La verificación se llevará a cabo por pares evaluadores, a los cuales se les establece un calendario para sus revisiones y se les otorga unas listas de comprobación o lista de chequeo para la revisión, también se les debe programar en el calendario un periodo de formación que los capacite para la tarea de revisión. Para esta práctica se cuenta con una plantilla en donde se indica los tiempos estimados que serán revisados por el área de desarrollo y calidad para cada actividad del requerimiento a desarrollar nos indica el tiempo de entrega de cada sprint. Aquí también debemos de poder identificar quienes participaran de esta verificación de cada sprint de acuerdo al listado de cada sprint por requerimiento. Tabla 27: Tiempos estimados de documentación, desarrollo y calidad Nombres de los Nombre de tarea Duración Comienzo Fin recursos mié mar Desarrollo Propuesta 10 días 04/11/15 17/11/15 Alcance técnico 1 días Percy Garcia Desarrollo del adicional 8 días Angelica Frias Angelica Frias / Revisión periódica 1 0.1 días Percy Garcia Angelica Frias / Revisión periódica 2 0.1 días Percy Garcia Angelica Frias / Revisión periódica 3 0.1 días Percy Garcia Angelica Frias / Revisión periódica 4 0.1 días Percy Garcia Testing del desarrollo 0.6 días Percy Garcia FUENTE: Elaboración Propia b. Llevar a cabo las revisiones entre pares (SP 2.2) En esta práctica se producen los resultados de la revisión entre pares, sobre los productos de trabajo que fueron seleccionados, identificando los problemas detectados de los productos de trabajo y los datos recogidos. Es posible que se haga necesaria una revisión adicional si se requiera. Los resultados deberán de ser comunicados a las partes interesadas o responsables del producto de trabajo, debe quedar una evidencia de esto. 62 Para esta práctica haremos uso del documento de revisión de pares en el cual se anota los participantes que intervienen en la verificación, la opción a evaluar, fecha de verificación, tiempo invertido, versión de la revisión. Además de indicar los puntos a verificar, los tipos de pruebas realizadas, en caso de haber una observación será enviada al área de Desarrollo para su corrección con ayuda de este documento. La plantilla de revisión de pares se encuentra en el anexo N° 1. c. Analizar los datos de la revisión entre pares (SP 2.3) Para esta práctica se recogen ciertos datos para el análisis, puede crearse un formato para ello debemos de registrar los datos relativos a la preparación, realización y resultados de la revisión entre pares. Los datos típicos son el nombre del producto, el tamaño del producto, la composición del equipo de la revisión entre pares, el tipo de revisión entre pares, el tiempo de preparación por revisor, la duración de la reunión de revisión, el número de defectos encontrados, el tipo y el origen del defecto, y así sucesivamente. Estos datos que se recogen deberán ser protegidos a fin que de no se les dé un mal uso o se destinen a propósitos indebidos. Los datos se analizan con el fin de detectar tendencias u oportunidades de mejora de los productos de trabajo. Los datos a analizar se encuentran plasmado en el documento de revisión de pares. De acuerdo a esta información se podrá elaborar un plan específico de mejora. La plantilla del plan específico de mejora se encuentra en el anexo N° 2. Este documento de plan específico de mejora contendrá la siguiente información:  Mejoras a realizar - Título - Objetivos  Grupo de trabajo  Macro de actividades  Reuniones 3.3.6. VERIFICAR LOS PRODUCTOS DE TRABAJO SELECCIONADOS (SG 3) Se deberían realizar las actividades de verificación durante todo el ciclo de vida del producto. Las prácticas relacionadas con las revisiones entre pares se incluyen en la meta específica 2 como un método de verificación específico. Esta meta específica requiere el cumplimiento de las siguientes prácticas específicas (SP):  Realizar la verificación (SP 1). 63  Analizar los resultados de la verificación (SP 2). a. Realizar la verificación (SP 3.1) Esta práctica producirá los resultados de la verificación o pruebas a los procesos para registrarlos tal como se ejecutan, debe producir documentos evidencia con estas características. Para esta práctica se utilizara el mismo documento de revisión de pares en la sección de tipos de Pruebas en el cual indicaremos brevemente los resultados realizados para la opción a evaluar. A continuación se muestra parte de la plantilla del documento de revisión entre pares, en donde se indica los tipos de pruebas. Figura 29: Parte del documento Revisión entre pares 64 En la plantilla del documento de revisiones entre pares se encuentra en el anexo N° 1. b. Analizar los resultados de la verificación (SP 3.2) Cuando se tiene los resultados listos se procede a su análisis con los procedimientos establecidos y se producen los resultados respectivos que revelarán los problemas encontrados, esto se logra haciendo una comparación entre los resultados esperados y los resultados reales obtenidos de la verificación, si los resultados esperados cumplen los criterios de aceptación establecidos, todo está bien, en caso contrario se deben iniciar acciones correctivas con peticiones de cambio. Para esta práctica se utilizara el mismo documento de revisión de pares en el cual al final del documento se enumerara los errores encontrados y las acciones a tomar por cada error encontrado, teniendo la opción a poder anexar documentación complementaria. Figura 30: Parte del documento Revisión entre pares 3.3.2 USO DE MÉTODOS AGILES PARA DAR SOPORTE AL PROCESO DE VALIDACIÓN Y VERIFICACIÓN A continuación se listan un conjunto de métodos ágiles que han sido identificadas como valiosos para ayudar en la preparación, revisión y ejecución de los procesos de validación y verificación: 65 a. Reunión de planificación de la entrega y priorizar las tareas más criticas En esta reunión se discute en términos generales cuál es el contenido que se va probar, se revisan los tiempos de entrega y los plazos, se revisan y discuten los riesgos. En la reunión se debe discutir sobre aquellas tareas que sean consideradas como las más críticas. Durante esta reunión se debe distribuir el contenido a verificar y se debe considerar el nivel de conocimientos que tenga cada miembro del grupo. b. El Scrum interdiario Esta técnica consiste en que el equipo de aseguramiento de la calidad se reúne interdiario para discutir:  Lo que se hizo desde la última reunión, el día anterior.  Lo que se va a hacer hasta la próxima reunión, es decir, hasta el día siguiente.  ¿Qué obstáculos tiene en su camino? Estas tareas están asociadas directamente con el contenido que es entregado por parte del equipo de desarrollo. La realización del Scrum permite identificar posibles riesgos, en especial porque se mencionan aquellos obstáculos o factores que alteran el curso normal de las actividades y permiten al Scrum Master en el caso particular del área de aseguramiento de la calidad, al gerente del área, tomar las decisiones en consenso con el grupo de trabajo y actuar de forma oportuna. 3.3.3. TRAZABILIDAD ENTRE LAS PRÁCTICAS ÁGILES Y LA VALIDACIÓN Y VERIFICACIÓN EN CMMI V1.3 En vista de que la propuesta de esta tesis es implantar un proceso de validación y verificación basado en CMMI v1.3 utilizando prácticas ágiles, es importante resaltar cuáles son las prácticas ágiles mencionadas a partir del punto 3.2.2 que ayudan a satisfacer las prácticas especificas del área de proceso de gestión de riesgos. Tabla 28- Trazabilidad entre las prácticas ágiles y validación en CMMI v1.3 Metas específicas del área de Practicas agiles identificadas proceso de validación de CMMI v1.3 que ayudan en la validación Preparar la validación Reunión de planificación de la entrega Validar el producto o los componentes Scrum interdiario de producto FUENTE: Elaboración Propia 66 Tabla 29 - Trazabilidad entre las prácticas ágiles y verificación en CMMI v1.3 Metas específicas del área de Practicas agiles identificadas proceso de verificación de CMMI que ayudan en la verificación v1.3 Preparar la verificación Reunión de planificación de la entrega Realizar revisiones entre pares Scrum interdiario Verificar los productos de trabajo Scrum interdiario seleccionados FUENTE: Elaboración Propia 67 3.3.4. DIAGRAMA DE PROCESO PROPUESTO Figura 31: Diagrama de proceso propuesto 68 a. DEFINICIÓN DEL PROCESO Tabla 30: Definición del Proceso Propuesto Proceso Definición Consultor recopila toda la información asociada a los requerimientos del cliente, tanto requerimientos funcionales como no funcionales. Consultor genera el documento de Alcance de Requerimiento con la información levantada del cliente y que le es presentada como sustento del trabajo que se va a realizar. Consultor identifica Actores y Casos de Uso involucrados en los requerimientos. Consultor prepara el diagrama de casos de uso indicando la relación entre actores y casos de uso. Consultor prepara los casos de uso identificados. Analista revisa los casos de uso e identifica necesidades o aclaraciones técnicas para el desarrollador (tablas o campos a crear, formato de archivos txt a generar o de salida, etc). Analista define las pruebas integrales a realizar y genera el documento "Casos de prueba integrales". Analista identifica los factores a testear y ejecuta PROTEST para determinar los casos de pruebas sugeridos. Tester prepara documento "Identificación de casos de prueba sugeridos". Analista prepara la matriz CRUD cruzando los casos de uso identificados vs. las tablas implicadas en cada uno e indica para cada tabla su nivel de acceso: C-crear, R-leer, U-actualizar, D-eliminar. Analista define las pruebas unitarias a realizar por el desarrollador y genera el documento "Casos de prueba unitarios". Analista utiliza la documentación de casos de uso entregado por el consultor y asocia a cada punto los temas técnicos necesarios para aclarar al desarrollador el trabajo a realizar. Tester consolida los documentos necesarios para efectuar el testing respectivo. 69 … continuación Tester consolida los documentos necesarios para efectuar el desarrollo respectivo. Desarrollador realiza la programación necesaria para cumplir con lo indicado en cada caso de uso. Desarrollador genera las pruebas unitarias en base a los casos de prueba entregados por QA. Supervisor revisa que el programa desarrollado cumpla con los standares de programación y de pantalla. Desarrollador consolida todas las pruebas realizadas, prepara el pack respectivo y las envía a QA. Tester efectúa las pruebas integrales definidas. Tester llena la Hoja de Seguimiento donde registra los resultados de las pruebas. Tester actualiza "Hoja de seguimiento" indicando consultor involucrado, casos de uso a desarrollar y desarrollador asignado. Tester rechaza el desarrollo porque contienen errores. Tester envía la solución testeada a Consultoría para su revisión final e implementación en el cliente. Consultor efectúa pruebas generales para validar el desarrollo entregado. Consultor rechaza la entrega final por errores detectados y lo devuelve a QA. Consultor implementa solución en el cliente. FUENTE: Elaboración Propia 70 3.3.5. NIVEL DE MADUREZ DE LA ORGANIZACIÓN CON RESPECTO A LAS ÁREAS DE PROCESOS DE VALIDACIÓN Y VERIFICACIÓN DEL CMMI V1.3 NIVEL 3 Según el desarrollo de los cuestionarios con respecto a cada uno de las áreas de procesos mencionado en la presente tesis se obtuvo los siguientes resultados:  Validación (VAL) : 30.55%  Verificación (VER) : 29.62% Como resultado se obtuvo que para la validación y verificación la organización se encuentra en un estado Limitadamente Cubierto con un 30.09% de prácticas específicas que se cumple en las 2 áreas de procesos. 3.3.6. ANÁLISIS POST DESARROLLO DE MODELO PROPUESTO a. ANÁLISIS DE LA VALIDACIÓN Tabla 31: Análisis de Validación del Modelo Propuesto Validación (VAL) Metas y prácticas específicas Porcentaje (%) SG 1 Preparar la validación SP 1.1 Seleccionar los productos a validar 16.66 SP 1.2 Establecer el entorno de validación 16.67 SP 1.3 Establecer los procedimientos y los criterios de validación 16.67 SG 2 Validar el producto o los componentes de producto SP 2.1 Realizar la validación 25.00 SP 2.2 Analizar los resultados de la validación 25.00 Resultado 100.00 FUENTE: Elaboración Propia 71 b. ANÁLISIS DE LA VERIFICACIÓN Tabla 32: Análisis de Verificación del Modelo Propuesto Verificación (VER) Metas y prácticas específicas Porcentaje (%) SG 1 Preparar la verificación SP 1.1 Seleccionar los productos de trabajo a verificar 11.11 SP 1.2 Establecer el entorno de verificación 11.11 SP 1.3 Establecer los procedimientos y los criterios de verificación 11.11 SG 2 Realizar revisiones entre pares SP 2.1 Preparar las revisiones entre pares 11.11 SP 2.2 Llevar a cabo las revisiones entre pares 11.11 SP 2.3 Analizar los datos de la revisión entre pares 11.11 SG 3 Verificar los productos de trabajo seleccionados SP 3.1 Realizar la verificación 16.67 SP 3.2 Analizar los resultados de la verificación 16.67 Resultado 100.00 FUENTE: Elaboración Propia 3.6. NIVEL DE CUMPLIMIENTO DE PRÁCTICAS POR CADA ÁREA DE PROCESO Para el cumplimiento de estas prácticas se tomó en cuenta el análisis basado en las prácticas requeridas por las áreas de proceso en estudio. 3.6.1. VALIDACIÓN A continuación se muestra un comparativo de los porcentajes de cumplimiento de las prácticas específicas del Área de Proceso Validación antes y después del desarrollo del modelo propuesto. 72 Validación (VAL) 25.00% 25.00% 25.00% 20.00% 16.66% 16.67% 16.67% 15.00% 16.66% 8.33% 10.00% 5.56% 5.00% 0.00% 0.00% 0.00% SP 1.1 SP 1.2 SP 1.3 SP 2.1 SP 2.2 Antes Optimo Figura 32: Comparación Validación antes y después del modelo propuesto Los resultados obtenidos del modelo propuesto y con el apoyo de los prototipos del proceso de Validación VAL, muestran que las practicas especificas se llegan a cumplir en un 100%, por lo que la meta especifica SG1 Preparar la Validación y SG2 Validar el producto o componentes de Producto se encuentran satisfechas, para poder cumplir con estas metas se debe de haber identificado los productos a validar bajo determinado procedimientos establecidos y analizar estos resultados para que ayuden a futuros desarrollos y validaciones de producto. 3.6.2. VERIFICACIÓN A continuación se muestra un comparativo de los porcentajes de cumplimiento de las prácticas específicas del Área de Proceso Verificación antes y después del desarrollo del modelo propuesto. Verificación (VER) 18.00% 16.67% 16.67% 16.00% 14.00% 11.11% 11.11% 11.11% 11.11% 11.11% 11.11% 12.00% 10.00% 8.89% 11.11% 8.00% 6.00% 3.70% 3.70% 4.00% 2.22% 2.00% 0.00% 0.00% 0.00% 0.00% SP 1.1 SP 1.2 SP 1.3 SP 2.1 SP 2.2 SP 2.3 SP 3.1 SP 3.2 Antes Optimo Figura 33: Comparación Verificación antes y después del modelo propuesto 73 Los resultados obtenidos del modelo propuesto y con el apoyo de los prototipos del proceso de Verificación VER, muestran que las practicas especificas se llegan a cumplir en un 100%, por lo que la meta especifica SG1 Preparar la Verificación, SG2 Realizar revisiones entre pares y SG3 Verificar los productos de trabajo seleccionados se encuentran satisfechas, para poder cumplir con estas metas se debe de haber identificado los productos a verificar bajo determinado procedimientos establecidos, documentar la revisión entre pares desde su preparación hasta su resultados de esta revisión evidenciando así la verificación para finalmente realizar el análisis de los resultados para tomar acciones correctivas. 3.7. NIVEL DE MADUREZ DE LA ORGANIZACIÓN BASADO EN EL MODELO PROPUESTO De acuerdo a las buenas prácticas del CMMI con respecto a cada área de procesos estudiada se obtuvo los siguientes resultados:  Validación: 100%  Verificación: 100% X (%) Diagnóstico Global = (% AP1 *50%)+ (% AP2 *50%) En base al porcentaje alcanzado por cada área de procesos se llega a cumplir las prácticas en un 100.00% teniendo en consideración que es un porcentaje ideal de las buenas prácticas del CMMI con Agiles, siendo así que:Con el modelo propuesto se mejora la calidad de los procesos para el ciclo de vida del desarrollo del software en un 69.91% que nos indica que se encuentra limitadamente cubierto, buscando así una adecuada gestión de la validación y verificación de producto basadas en la buenas prácticas de CMMI nivel 3 y Agiles Scrum con lo cual deberemos tener un seguimiento de estos procesos en base a reuniones inter-diarias. 3.8. PROPUESTA DE IMPLEMENTACIÓN DEL ÁREA DE PROCESO DE VALIDACIÓN Y VERIFICACIÓN DEL CMMI V1.3 SOPORTADO POR METODOLOGÍAS AGILES A pesar de que la propuesta de implementación del área de proceso de validación y verificación del CMMI v1.3 soportado por metodologías agiles aún no se ha llevado a cabo, por lo que únicamente serian relevantes los fundamentes teóricos de ambos apartados para la evaluación, es en base a este modelo como propongo que se evalué la propuesta de llevarse a cabo de manera real. Sin embargo se realizó un piloto en donde se detalla en el punto 3.8.1. Como se sabe el problema principal que se tiene es la demora en la entrega de producto y la calidad de este producto por lo cual para poder explicar o sustentar nuestra propuesta tomaremos como ejemplo la implementación de Facturación Electrónica. En este caso tomaremos como muestreo un grupo de 8 clientes a los cuales se les ha ofrecido el módulo de facturación electrónica. 74 Tabla 33: Clientes que optaron por trabajar con otro proveedor Cliente Acepto Propuesta Opto por otro Proveedor Corporación Miya X Eupen del Viru X Presión Perú X Mundosa X Sanihold X Knight Sol X Rayos Peru X Terminal Peruano X FUENTE: Elaboración Propia Total Clientes = 8 Acepto Propuesta = 5 Optó por otro Proveedor = 3, Porcentaje Optó por otro proveedor = 3/8*100 = 37.5% De acuerdo a la tabla se tiene que el 37.5% de este muestreo opto por otro proveedor por los problemas de calidad de producto y demora en entrega se perdió la confianza que nos tenía estos clientes. Cuando se consultó a los clientes por qué no realizan la implementación completa con OFISIS la respuesta de los 3 clientes fue: “la demora que han tenido en otros proyectos y la calidad de entrega de esos productos”, a nivel de costos cuando optaron por otro proveedor la diferencia de costo entre un proveedor y otro, en ocasiones, superaban el costo propuesto por OFISIS: OFISIS: $14,000.00 Otro Proveedor: $16,000.00 Como pueden observar en las cifras mencionadas líneas arriba OFISIS ha dejado de percibir en solo 3 clientes $42,000.00 (costo de oportunidad), solo porque el cliente tuvo una mala experiencia con otros trabajos (desarrollo) brindado por OFISIS optando por otros proveedores. Para poder evitar seguir teniendo está perdida de cliente e insatisfacción del cliente se optó por mejorar el proceso de validación y verificación en el área de calidad que se explica en esta tesis. Uno de los beneficios obtenidos en esta presente tesis es recuperar la confianza que tenían nuestros clientes, mantener y captar nuevos clientes que podrán ser recomendados por estos mismos. 3.8.1. IMPLANTACIÓN DEL PROCESO PILOTO Se realizó una prueba piloto en uno de los proyectos de OFISIS en donde involucraba desarrollo, para tal prueba se escogió la implementación de proyectos de Facturación Electrónica. En esta prueba se pudo determinar que las garantías del producto se redujeron en un 38.80%. 75 A continuación se muestra como evidencia dos proyectos de Facturación Electrónica en donde uno se implementó de la forma estándar de OFISIS y el otro con la propuesta de solución planteada en esta tesis. Tabla 34: Comparación de horas de garantías de proyectos con la propuesta de tesis. CLIENTE SERVICIOS HORAS PROPUESTA DE TESIS Sanihold Garantía 33.50 Sanihold Proyecto 256.75 Presión Perú Garantía 20.50 X Presión Perú Proyecto 233.75 X FUENTE: Elaboración Propia Como se puede apreciar en la tabla 29 se demuestra que el piloto implementado el tiempo de garantía ha reducido de 33.50 horas a 20.50 horas, porcentualmente viene ser 38.81% de reducción de garantías. X = Horas de Garantía de proyecto sin propuesta de tesis Y = Horas de Garantía de proyecto con propuesta de tesis X = 33.50, Y = 20.50 Porcentaje reducido = ( 100 - ( 20.50 / 33.50 ) * 100 ) = 38.81% A continuación se muestra en la figura la reducción de tiempo de garantías en el piloto realizado: 300.00 250.00 200.00 Sanihold 150.00 Presión Perú 100.00 50.00 - Garantia Proyecto Figura 34: Comparación de horas de garantías de proyectos con la propuesta de tesis 76 3.8.2. ANALISIS DE OPORTUNIDAD Se realizaron evaluaciones adicionales para poder sustentar nuestra propuesta que es viable económicamente encuestando también a nuestros clientes sobre la satisfacción del servicio que brinda OFISIS. A continuación se muestra en la figura 35 el resultado de la encuesta realizado a 7 clientes al azar: Area de Inconformidad - Causa 5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 Soporte Tecnología Consultoría Mal Servicio 2 1 Funcionalidad del producto 5 Tiempos de respuesta 3 3 1 Falsa expectativa 1 1 Figura 35: Análisis de inconformidad del cliente por áreas de OFISIS De esta grafica podemos obtener que la mayor incidencia de inconformidad se tiene en el área de tecnología en el cual involucra el tiempo de respuesta y la funcionalidad del producto. Otro punto a observar es que el área de soporte también tiene deficiencias en el servicio y tiempos de respuesta, y esto se debe a que esta área tiene una sobrecarga de trabajo por la cantidad de garantías que lo genera el área de tecnología. Con nuestra propuesta mencionada en esta tesis estaríamos mejorando los dos puntos críticos que son la funcionalidad del producto y tiempos de respuesta. Permitiendo así mejorar la satisfacción del cliente y haciendo que la fidelización con OFISIS se intensifique, logrando que sean unos clientes promotores. 77 CAPITULO IV - DISCUSIÓN 78 4.1. DISCUSIÓN Es importante que para toda mejora de procesos se realice un análisis y evaluación de la situación actual de la empresa OFISIS con respecto al modelo CMMI Dev 1.3 soportado por la metodología ágil, por tal motivo es que para la empresa en estudio se obtuvo una mejora de 69.91% con respecto a su situación actual que era un 30.09%. Con esta mejora de procesos se logrará tener una adecuada validación y verificación de los desarrollos de software para reducir los cuellos de botellas que son generados en los procesos de desarrollo y para la entrega de un producto de calidad. El desarrollo del proceso de revisiones continuas SCRUM de los desarrollos se consideró de suma importancia para llevar a cabo una adecuada validación y verificación de los mismos, ya que permite tener el conocimiento e información necesaria para tomar una medida correctiva anticipada si es que se desvía de lo que se tiene planificado. Este proceso fue importante para poder reducir las horas de trabajo extras que se realiza en la empresa en estudio. Implantar CMMI con SCRUM es posible, ya que muchas empresas en la actualidad lo han realizado, ya que ambas metodologías nos ayudan a la mejora de la calidad de procesos en base a sus buenas practicas. Aplicación en otras Áreas de Procesos. La metodología aplicada en la presente tesis puede ser tomado como referencia para el desarrollo de las demás áreas de procesos que no han sido tocado debido al alcance del proyecto como son: Gestión de Requerimientos y Gestión de riesgos, de los procesos mencionados ayudaría para poder llegar a revalidar las áreas que exige CMMI para alcanzar el nivel 3. Aplicación del modelo a otras empresas. Si bien es cierto este modelo de mejora de procesos basado en CMMI Dev 1.3 ha sido desarrollado para una empresa de servicio de software, este puede ser aplicado en otras empresas que cuenten con áreas de desarrollo de software o que se encuentren en el rubro de desarrollo de software, pero se debe tener en cuenta que este modelo ha sido desarrollo para 2 áreas de procesos que son de prioridad para el negocio de la empresa en estudio. Planteamiento de nuevas Hipótesis De acuerdo al estudio realizado en la presente tesis se obtuvo una nueva hipótesis a estudiar y esta se encuentra en el área de proceso de gestión de requerimientos, ya que de acuerdo a las encuestas realizadas se obtuvo que un gran índice de errores de desarrollo se debe a que los requerimientos solicitados por el cliente no estaban detallado de tal forma que el desarrollador pueda transcribir en el software lo que realmente requiere el cliente. 79 CAPITULO V - CONCLUSIONES Y RECOMENDACIONES 80 5.1. CONCLUSIONES La presente tesis tiene como objetivo dar una propuesta de implementación del área de proceso de validación y verificación del CMMI v1.3 soportado por metodología ágil a la consultora de sistemas OFISIS, cuya finalidad es optimizar los tiempos de entrega de los desarrollos y calidad de los mismos. Para demostrar esto, primero se realizó un análisis de la situación actual de la empresa OFISIS, en la cual pudimos observar que el departamento de calidad carece de una metodología de control de calidad en el proceso del desarrollo del software a pesar que tuvo la certificación del CMMI nivel 3 en los años 2011. En este proceso de mejora de la calidad se realizó la investigación del marco teórico delas áreas de procesos de validación y verificación del CMMI v1.3 y la metodología ágil, con la finalidad de mejorar los procesos de calidad que carece el departamento de calidad de la empresa OFISIS, basándonos en las buenas practicas que sugiere estas metodologías. Con el piloto realizado se pudo demostrar que la calidad del producto mejoró notablemente ya que las garantías del producto se redujeron. En esta propuesta de acuerdo al piloto desarrollo se obtuvo una reducción significativa de las garantías de los desarrollos en un 38.81%, aun mayor a lo indicado en nuestro objetivo específico. Definitivamente observamos que nuestra propuesta permite que la consultora de sistemas OFISIS recupere su nivel de satisfacción del cliente, ya que de acuerdo a nuestro piloto realizado pudimos verificar que el tiempo del proyecto tuvo una reducción con respecto a otros proyectos similares implementados sin nuestra metodología. Es importante mencionar que al terminar la implementación del piloto el cliente entregó su carta de conformidad. En esta propuesta se pudo identificar también que el área de soporte de OFISIS también cuenta con una deficiencia en los tiempos de atención por la sobrecarga de trabajo por la cantidad de garantías que provoca el área de tecnología. Cabe mencionar que también debido a los problemas de calidad del producto y de tiempos de entrega que se han presentado en OFISIS también ha afectado que nuestros clientes no trabajen con OFISIS por estos problemas, optando el poder trabajar con otros proveedores lo cual perjudica económicamente a OFISIS. Actualmente existe otro grupo de clientes que también muestran estos mismos malestares y que pueden también dejar de trabajar con OFISIS, justamente para evitar que estos clientes se vayan con otros proveedores, con nuestra propuesta se busca mejorar la satisfacción del cliente. 81 5.2. RECOMENDACIONES Si bien es cierto este modelo de mejora de procesos basado en CMMI Dev 1.3 soportado con metodología ágil ha sido desarrollado para una empresa de servicio de software, este puede ser aplicado en otras empresas que cuenten con áreas de desarrollo de software o que se encuentren en el rubro de desarrollo de software, pero se debe tener en cuenta que este modelo ha sido desarrollo para 2 áreas de procesos que son de prioridad para el negocio de la empresa en estudio. Recomendamos que las empresas que se encuentren en la misma situación que la empresa en estudio pueda realizar la revalidación de la certificación CMMI V1.3 una vez que hayan aplicado nuestra propuesta de Tesis. Con el avance de la tecnología y la necesidad de brindad un mejor servicio al cliente, podemos optar por esta solución de integración de CMMI y metodología Ágil. Se considera interesante investigar sobre otros aspectos relacionados al control de calidad del software y el tiempo de entrega de los mismos: Extender los estudios expuestos en esta tesis al estudio del área de proceso de gestión del requerimiento y gestión de riesgos del CMMI v1.3 ya que al realizar este estudio se pudo identificar que un alto porcentaje de error de programación se debe a que los requerimientos de los clientes no se encuentran bien definidos. Así mismo, poder identificar los riesgos con anticipación y mitigarlos nos ayudaría el estudio de la gestión de los riesgos. Analizar otras áreas de la empresa en donde la situación sea crítica para la empresa y en donde el cliente final no se encuentre totalmente satisfecho con el servicio que se les brinda, como por ejemplo el departamento de soporte. 82 CAPITULO VI - REFERENCIAS BIBLIOGRÁFICAS 83 6.1. REFERENCIAS BIBLIOGRÁFICAS Software Engineering Process Management Program, (2010) CMMI para desarrollo, versión 1.3. http://www.sei.cmu.edu/library/assets/whitepapers/Spanish%20Technical% 20Report%20CMMI%20V%201%203.pdf. Consultado en: [octubre 2015] Ken Schwaber y Jeff Sutherland, (2013) La Guía de Scrum http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf Concha Huacoto, Nancy. (2005). Propuesta para Implantar CMMI en una empresa con múltiples unidades desarrolladoras de software. Universidad Mayor de San Marcos, Lima -Perú. Recuperado dehttp://sisbib.unmsm.edu.pe/bibvirtualdata/tesis/basic/concha_hn/concha_hn.pdf Rodrigo Torres Garibay, Sg virtual scrum+cmmihttp://es.slideshare.net/RevistaSG/sg- virtual-scrumcmmi 84 CAPITULO VII - GLOSARIO 85 7.1. GLOSARIO Caso de Uso: Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores. Revisión entre pares: Es un método usado para validar trabajos escritos y solicitudes con el fin de evaluar su calidad. Requerimiento funcional: Define una función del sistema de software o sus componentes. 86 CAPITULO VIII - ANEXOS 87 ENCUESTAS Anexo A - Encuesta para Calidad 1. ¿Realizan reuniones de áreas semanales para revisar lo ejecutado vs lo planificado? a) Siempre b) Eventualmente c) Nunca 2. Cuando se realiza la validación y verificación del desarrollo, ¿en qué documento se apoya? a) Alcance Funcional b) Alcance Técnico c) Alcance Funcional y Técnico d) De acuerdo a la experiencia del consultor funcional 3. ¿Se cuenta con el ambiente necesario para realizar la validación y verificación de los desarrollos? a) Si b) No 4. ¿Se establece criterios y procedimientos para la validación y verificación de los desarrollos? a) Si b) No 5. ¿Los resultados de la validación y verificación, son debidamente documentados? a) Siempre b) Eventualmente c) Nunca 6. ¿Se realiza un proceso de análisis de los resultados de la validación y verificación, para medidas correctivas? a) Siempre b) Eventualmente c) Nunca 88 Anexo B - Encuesta para Consultoría 1. Si tuvieras que calificar la calidad del desarrollo entregado, ¿cómo lo calificarías? a) Excelente b) Bueno c) Regular d) Malo 2. ¿Se realiza la entrega de los desarrollos de acuerdo a los tiempo planificados? a) Si b) No 3. Cuando se tiene observaciones en el proceso de validación con el usuario, ¿se documenta esta observación y a qué área se informa? a) Por correo y al área de calidad b) A través del registro de incidencias c) Por correo y al área de desarrollo d) No lo reporta 4. En caso los desarrollos vayan a tener una demora en la entrega, ¿se informa al cliente oportunamente? a) Si b) No 5. Cuando se termina con la implementación de lo desarrollado en el cliente, ¿se realiza algún tipo de documentación? a) Si b) No 89 Anexo C - Encuesta para Desarrollo 1. Usted, ¿actualmente cuenta con un trabajo planificado? a) Si b) No 2. En cuanto a los errores presentados en el desarrollo de un producto, ¿qué tipo de errores ha tenido usualmente? a) Error por compilación de librerías b) Error de versionamiento c) Error funcional de acuerdo al requerimiento del cliente d) Otros 3. ¿Se realiza supervisión de los desarrollos asignados? a) Siempre b) Eventualmente c) Nunca 4. ¿Se realiza documentación detallada de lo desarrollado y/o correcciones? a) Siempre b) Eventualmente c) Nunca 5. Cuando se da por terminado un desarrollo, ¿se hace entrega de alguna documentación sobre este proceso? a) Si b) No 90 Anexo N° 1 - REVISION ENTRE PARES Sistema : ACTIVO FIJO............ CONTABILIDAD................... LOGÍSTICA................ PRESUPUESTOS.... PRODUCCION..................... R. HUMANOS............ SEGURIDAD............ TESORERIA......................... VENTAS.................... OTROS......................... Modulo : Opción Validada: Analista : Fecha de Entrega : Roles participantes en la Verificación: - Analista : Desarrollo de la opción a validar – verificar - Jefe de Proyecto / Gerente de Proyecto: Revisor Revisión de Pares Revisor : Fecha Revisión : Tiempo Invertido : Número de Revisión : 01 (correlativo por opción verificada) APT: Analista Revisor MANTENIMIENTOS Aprob. Desap. o Título de Pantalla o Etiqueta de la pantalla o Funcionamiento de los F5 (título, información, validar seguridad) o Mensajes de validación (Probar todos los mensajes, Que tengan la descripción correcta) o Habilitación y/o Deshabilitación Botones o Carga información Child Tables (títulos de columnas, tipo dato, tamaño, Grabar Valores en todas las columnas, y verificar que carguen, con el valor correspondiente) o Validar NO visualización Scroll en la pantalla 91 o Título de TAB o Funcionamiento de TAB (Habilitación MENU) o Grabación información (Error primary key, foreing key, reglas,etc) o Uso correcto de Selects (validar Where, join, optimización) o Funcionamiento Objetos de pantalla (radio botton, check box,etc) o Visualización correcta de la fecha y usuario (modificación, creación) en la pantalla o Uso de variables del form Usar las variables globales, y colocar siempre el owner a cada variable local. o Uso objetos estándares o Verificar los Tab Orders REPORTES o Verificar la existencia del reporte, qrp, y modo tabla (mostrar columnas con título), o Si es procedure, mostrar todas las columnas con título. o Verificar nombre de títulos, formato fecha (dd/mm/aaaa), formato de números (validar estándares) o Verificar totales emitidos (todos los reportes deben tener total 92 general y totales parciales por cada quiebre existente) o Verificar funcionamiento adecuado al utilizar la pantalla de “filtros”. PROCEDURES: o Actualización de la Cabecera o Comentarios sobre función del procedure o Si tiene una función local, que hace esa función. o Excepciones o limitaciones del proceso. o Uso correcto de Selects (validar Where, join, optimización) o Verificar que el programador no haya dejado un “select” de prueba para una variable determinada. TIPOS DE PRUEBAS - La verificación realizada cumple con el requerimiento solicitado - Cumple con los estándares de programación vigentes - Tipos de pruebas realizadas (integración con otros productos) - La verificación se dio en un entorno de prueba similar al de producción. (porque?) 93 - Con que cantidad de registros se ha realizado la verificación - Con cuantos periodos de información se ha realizado la validación 94 Problemas Encontrados Acciones a Tomar Se anexa documentación : _______________________________________________________________ _______________________ Vo.Bo. Gerente / Jefe de Proyecto 95 Anexo N° 2 - PLAN ESPECÍFICO DE MEJORA 1. Mejoras a realizar No MEJORA No MEJORA No MEJORA DESCRIPCIÓN 1. OBJETIVOS 2. 2. Grupo de trabajo (GT) Líder: 1. 2. Integrantes: 3. 4. 5. Facilitador: Manuel Behar – Gerente General Autoriza: Alberto Muñoz – Gerente Comercial 4. Macro Actividades Fecha Inicio Fecha Fecha Fin Fecha Macro Actividad Programada Inicio Real Programada Fin Real 1. Diseño de la Solución 2. Pilotaje 3. Despliegue 5. Reuniones Fecha Programada 1. Reunión Revisión del Diseño 2. Entrega informe Pilotaje 3. Informe de Despliegue 96 Anexo N° 3 - ALCANCE DE REQUERIMIENTO CCCCCCCC_SSSS_2015_MM_001A_F Cliente : ________________________________________________________ Área / Dpto. : _____________________________________________________ Solicitante : ___________________________Fecha Solicitud : __ / __ / ____ Ofisis Tipo de Servicio: Venta Actualización Versión Adicional Recepción : _________________________Nro. Trabajo: ________________ Área / Dpto. : _____________________________________________________ Informado a : ___________________________Fecha Informe : __ / __ / ____ Sistemas : _______________________________________________________ Nombre del Requerimiento: Un título que abarque el o los requerimientos que se contemplen en la solicitud del cliente. Detalle brindado por el Cliente: Proporcionar la información de la solicitud del cliente, si es posible transcribir textualmente lo enviado. Objetivos del Requerimiento: Especificar qué objetivos se cumplen con la ejecución del requerimiento Documentación anexa: ______________________________________________ ______________________________________________ 97 Análisis Funcional Responsable : _________________________________ Fecha: __ / __ / ____ Alcance: De manera macro se plantea funcionalmente una o más soluciones (en caso de ser más de una identificarla como se hacía en el anterior formato alternativa A y Alternativa B), la descripción debe ser de forma general sin especificar mayor detalle. Debe establecerse si la solicitud debe abarcar soluciones cliente – servidor, web, de inteligencia de negocios u otro. De igual forma se identificará interacción con otros sistemas (para el caso de interfaces). En el caso de Requerimientos de Ventas esta sección es la que se referenciaría para dar los tiempos “macro”. Especificación: Esta sección amplia el análisis del requerimiento llegando a detallar las pantallas, reportes u otros objetos con los cuales el usuario deberá interactuar. Se debe contemplar el detalle de los parámetros que ingresará el Usuario así como referencia de los resultados esperados. En el caso de reportes se debe contemplar un anexo con la estructura de la información. Casos de Uso: Dependiendo de la complejidad del requerimiento es necesario contemplar casos de uso como referencia de la interacción. Consideraciones: Dependiendo del desarrollo y el alcance en esta sección se debe listar aquellos temas que NO SE VAN A CONTEMPLAR o que NO SON PARTE DEL DESARROLLO, importante puntualizarlo para hacer más claro el marco que limita el entregable. 98 Detalle de Tiempos Información de los tiempos diferenciados por funciones y tareas. Nota: Los tiempos están dados en días ENTORNO DE TRABAJO Trabajo realizado en: OFISIS [X] Cliente [ ] INFORMACION DE PLATAFORMA Herramienta Utilizada: CENTURA…….………… .NET…… REPORTING SERVICE Base de Datos SQL Server ______ ORACLE ______ Otro ____________ Nombre del servidor: ____________________________________________ Ambiente: Test []fecha de restauración: _/_/_ Producción [ X ] Sistema Operativo (Servidor) Sistema Operativo (PC) Versión Versión Windows Server 2012 Windows 8 Windows Server 2008 Windows Vista Linux _________ Windows XP Unix _________ _________ _________ ______________ _________ Microsoft Office: versión _______ español [ ] inglés [ ] Usuario de Prueba: Código __OFISIS _______________________________________________ 99 Anexo N° 4 - ESTANDARES DE NOMBRES a) Tablas Formato WZYYYY[_YYYY][_AAAAPP] (De 6 a 18 caracteres, todo en mayúsculas) donde : W T = Tabla, H = Histórico, P = Pruebas Z M = Maestro, A = Acumulado, C = Cabecera, D = Detalle, R = Relación, T = Apoyo, W = Temporal, X = Cabecera + Detalle, V = Vistas YYYY_YYYY Nemotécnico de la tabla (2 grupos unidos por '_') AAAAPP Para el caso de históricos : AAAA= Año, PP = Periodo Al nombre de las tablas temporales que son usadas por stored procedures se le adicionará la constante de éste y un número correlativo empezando en 1, con incrementos de 1 en 1. Ejm : TWMVTO_CNTB_AZZ_N donde : A Constante Q = Query, I = Insert, D = Delete, U = Update, T = Apoyo ZZ Correlativo numérico del stored procedure N Correlativo(empezando en 1 e incrementos de 1 en 1) b) Indices de las Tablas (Creados por el Usuario) Formato IWXYYYY[_YYYY][_AAAAPP]_NN (De 10 a 22 caracteres, en mayúsculas ) donde I Constante de Indice W T = Tabla, H = Histórico, P = Pruebas X M = Maestro A = Acumulado C = Cabecera D = Detalle R = Relación W = Temporal X = Cabecera + Detalle YYYY_YYYY Nemotécnico de la tabla ( 2 grupos unidos por ‘_ ‘) AAAAPP Para el caso de históricos “AAAA = Año, PP = Periodo) NN Correlativo numérico del Indice c) Atributos de Tablas (Columnas) Formato PP_YYYY_YYYY ( Entre 7 a 12 caracteres, todo en mayúsculas ) donde PP Prefijo según tabla actual o anexa YYYY_YYYY Nemotécnico de la columna( 2 grupos unidos por ‘_ ‘) 100 d) Variables en el Programa Centura Formato wPP_YYYY[_YYYY] (de 8 a 13 caracteres, todo en mayúsculas, excepto el prefijo) donde : w Prefijo que identifica el tipo de variable : n =Numérico, b = Booleano, d = Fecha, s = String, l = Long String PP_YYYY_YYYY Nombre del atributo o similar a su estructura Ejm: sCO_EMPR (String) nIM_CNTB_EMPR (Number) dFE_DOCU (Date) bOK_CODI (Boolean) Nuevas Variables : Se han agregado las siguientes variables : - sRU_EXES : ruta de Exes (en reemplazo de sPATH) - sRU_QRPS : ruta de QRPs. Excepciones al estándar : Sólo están exentas las variables de programación como : hSql, hWnd, fh (file handle) o bOK (cuando es de sólo 3 caracteres). e) Menú en el Centura (MDI) Formato MSSZ0001 ( 8 caracteres, todo en mayúsculas ) donde M M Mdi Window SS Nombre del sistema Z Nombre del módulo ( Ejemplo : MPLA0001 ) Donde : Del 2do. al 3er. caracter es el sistema, ( Ejemplo : AC = Activo Fijo, CO = Contabilidad, LO = Logística, PL = Recursos Humanos, SE = Seguridad, PR = Presupuestos, TE = Tesorería ) El 4to. caracter es el módulo ( Ejemplo : A = Administración E = Empresa ) 101 f) Ventanas en el Centura Formato TSSMWZZ ( 7 caracteres, todo en mayúsculas ) donde T Prefijo que identifica el tipo de ventana F Form Window, D Dialog Box SS Nombre del sistema M Nombre del módulo W Opción del menú principal ZZ Correlativo de ventanas (alfabético). Cada Opción del Menú tiene su propio correlativo Por Ejemplo : Opciones Mantenimiento empieza en AA .. Opciones Tablas empieza en AA .. (Empieza en AA, luego AB, AC,...,AZ, BA, BB, ...) (Ejemplo : FPLEMBC ) Donde : El 1er. caracter es el tipo de ventana, Del 2do. al 3er. caracter es el sistema, ( Ejemplo : AC = Activo Fijo, CO = Contabilidad, LO = Logística, PL = Recursos Humanos, SE = Seguridad, PR = Presupuestos, TE = Tesorería ) El 4to. caracter es el módulo del sistema ( Ejemplo : A = Administración E = Empresa El 5to. caracter es la opción del menú ( Ejemplo : E = Selección de Empresa, M = Mantenimiento, P = Procesos, T = Tablas, R = Reporte, A = Ayuda) Del 6to. al 7mo. caracter es el correlativo (alfabético) g) Reportes (QRP) 102 Formato TSSMWZZN[_YY] ( 8 a 11 caracteres, todo en mayúsculas ) donde T Prefijo que identifica el tipo de ventana F Form Window, D Dialog Box SS Nombre del sistema M Nombre del módulo W Opción del menú principal ZZ Correlativo de ventanas (alfabético) (por cada opción del menú principal) (Empieza en AA, luego AB, AC,...,AZ, BA, BB, ...) N Correlativo de QRP´s por cada Ventana (opción del menú) Empieza en 1, se incrementa de 1 en 1. Si es que hay más de 9, el décimo hacia adelante se le colocaran letras, empezando con la ‘A’, continuando en orden alfabético. _YY Prefijo del nombre del cliente (sólo cuando se realiza una modificación o un reporte nuevo.) (Ejemplo : FPLEMBC2 ) Donde : El 1er. caracter es el tipo de ventana, Del 2do. al 3er. caracter es el sistema, ( Ejemplo : AC = Activo Fijo, CO = Contabilidad, LO = Logística, PL = Recursos Humanos, SE = Seguridad, PR = Presupuestos, TE = Tesorería ) El 4to. caracter es el módulo del sistema ( Ejemplo : A = Administración E = Empresa El 5to. caracter es la opción del menú ( Ejemplo : E = Selección de Empresa, M = Mantenimiento, P = Procesos, T = Tablas, R = Reporte, A = Ayuda) Del 6to. al 7mo. caracter es el correlativo (alfabético) 103 El 8vo. caracter es el correlativo h) Objetos en las Ventanas Formato wwYY_YYYY[_YYYY] (De 9 a 14 caracteres, todo en mayúsculas menos los 2 primeros caracteres) donde : ww Prefijo que identifica el tipo de objeto df =Data Field, cb = ComboBox, ct = Child table, pb = Push Botton, lb = List Box, pc = Picture, rb = Radio Botton, cl = Column Table, ch = Check Box, mf = Multiline Field YY_YYYY[_YYYY] Nombre del objeto Ejm: dfFE_DOCU En los data fields, cuando tenemos la opción de rangos (de fechas, de códigos, etc), la manera correcta de codificar es la siguiente : Ejm: dfFE_DOCU_INIC dfFE_DOCU_FINA dfCO_DOCU_CRED_INIC dfCO_DOCU_CRED_FINA Donde : “_INIC” y “_FINA” se agregan al final del data field. i) Constantes de Mensajes en Centura Formato XX_YYYY_YYYY ( Entre 7 a 12 caracteres, todo en mayúsculas ) donde XX Constante “WM” que identifica Mensajes Windows Constante “AM” que identifica Mensajes del programa. Usar a partir del SAM_USER + 60 YYYY_YYYY Descripción del mensaje Nota : La definición de Mensajes Adicionales no es permitida, salvo autorización expresa del Jefe de Proyecto, en la Clase están definidos distintos Mensajes que soportan la mayoría de los que se pueden usar j) Tipos de Datos Formato TD_XX_EEE[_D][_YYYY] ( Entre 9 a 16 caracteres, todo en mayúsculas ) donde TD Constante “TD” que identifica a un Tipo de Dato XX Sufijo que identifica un tipo de dato CH Character, DT DateTime, VB VarBinary, 104 VC VarChar, SI SmallInt, TE Texto, BT Bit, IN Integer, NU Numeric, TI TimeStamp, IM Image EEE Es un número de enteros D Número de decimales YYYY Para el caso de tipos especiales (estado) Nota : NO USAR : Smalldatetime, Float y Money En el caso de variables de cadena con longitud menor a 3 se debe definir CHAR, caso contrario colocar VARCHAR k) Reglas de Validación y Defaults Formato XX_YYYY_YYYY ( Entre 7 a 12 caracteres, todo en mayúsculas ) donde XX Constante “RV” que identifica una Regla de Validación Constante “DF” que identifica un Default YYYY_YYYY Descripción libre del mensaje l) Stored Procedures y Cursores Formato UU_WXYYYY[_YYYY]_AZZ ( Entre 14 a 19 caracteres, todo en mayúsculas ) donde UU Constante “SP” que identifica un Store procedure Constante “CU” que identifica un Cursor CT Constante “CT” que identifica un Cursor de un Trigger. WXYYYY_YYYY Nombre de la Tabla W T = Tabla H = Histórico P = Pruebas X M = Maestro A = Acumulado C = Cabecera D = Detalle R = Relación T = Apoyo W = Temporal X = Cabecera + Detalle YYYY_YYYY Nemotécnico de la tabla ( 2 grupos unidos por ‘_ ‘) A Constante Q = Query, I = Insert, D = Delete U = Update ZZ Correlativo Numérico A los SP’s estándares que sean modificados especialmente para un cliente se le pondrá el siguiente nombre : - Ejm: SP_TWMVTO_CNTB_Q01  XX_TXMVTO_CNTB_Q01 Donde : XX : Siglas del Cliente (Verificar lista de Prefijos definidos) A los Cursores, al igual que a las tablas temporales se le adicionará un número correlativo. - Ejm: 105 CU_TXMVTO_CNTB_Q01_1 CU_TXMVTO_CNTB_Q01_2 CT_TXMVTO_CNTB_Q01_1 CT_TXMVTO_CNTB_Q01_2 m) Triggers Formato UU_WWYYYY_YYYY_AZZ ( Entre 14 a 19 caracteres, todo en mayúsculas ) donde UU Constante “TR” que identifica un TRIGGERS WXYYYY_YYYY Nombre de la Tabla W T = Tabla H = Histórico P = Pruebas X M = Maestro A = Acumulado C = Cabecera D = Detalle R = Relación T = Apoyo W = Temporal X = Cabecera + Detalle YYYY_YYYY Nemotécnico de la tabla ( 2 grupos unidos por ‘_ ‘) A Constante I = Insert, D = Delete, U = Update ZZ Correlativo Numérico n) Constantes para Stored Procedures en Centura Formato UU_SP_WXYYYY[_YYYY]_AZZ ( Máximo 22 caracteres, todo en mayúsculas ) donde UU Constante “VE” que identifica Variable de Entrada Constante “VS” que identifica Variable de Salida Constante “VM” identifica Variables Mixtas (I/O) SP_WXYYYY_YYYY Nombre del Stored Procedure W T = Tabla H = Histórico P = Pruebas X M = Maestro A = Acumulado C = Cabecera D = Detalle R = Relación T = Apoyo W = Temporal X = Cabecera + Detalle A Constante Q = Query, I = Insert, D = Delete U = Update ZZ Correlativo Numérico o) Programa Cliente APT Formato SSMM0001 ( 8 caracteres, todo en mayúsculas ) donde SS Prefijo que identifica el tipo de Sistema ( Ejemplo : AC = Activo Fijo, CO = Contabilidad, 106 LO = Logística, PL = Recursos Humanos, SE = Seguridad, PR = Presupuestos, TE = Tesorería ) MM identifica el módulo ( Ejemplo : AD = Administración, CO = Corporación, EM = Empresa ) Ejemplo : COEM0001.APT : APT del módulo de Empresa del Sistema de Contabilidad p) Programa Cliente APT – Sistema (NUEVO) - El nombre del APT de los Sistemas (para el Menú Principal del OFISmart, para el inicio de cada Sistema) será de la siguiente manera : Ejemplo : - INAC0001.APT : APT del Sistema de Activo Fijo - INCO0001.APT : APT del Sistema de Contabilidad - INLO0001.APT : APT del Sistema de Logística - INPL0001.APT : APT del Sistema de Recursos Humanos - INSE0001.APT : APT del Sistema de Seguridad - INPR0001.APT : APT del Sistema de Presupuestos - INPR0001.APT : APT del Sistema de Producción - INTE0001.APT : APT del Sistema de Tesorería - INVE0001.APT : APT del Sistema de Ventas 107 Anexo N° 5 - BASE DE DATOS (LOGICO) El objetivo es estandarizar los nombres de los modelos de Erwin, los scripts de las bases de datos, los nombres de las tablas y los atributos (columnas). Erwin : SSyymmdd.ER1 Donde : SS -> Nombre del Sistema yy -> año mm -> mes dd -> día Script : Los Stored Procedures relacionados a cada tabla serán recopilados en un mismo archivo de texto, cuyo nombre será el de la tabla. (Ejemplo : Tabla -> TXMVTO_CNTB, donde los SP son : Sus SP´s se llamarían : SP_TXMVTO_CNTB_D01 SP_TXMVTO_CNTB_I01 SP_TXMVTO_CNTB_U01 SP_TXMVTO_CNTB_Q01 SP_TXMVTO_CNTB_Q02 El Archivo sería TXMVTO_CNTB.SQL ) Tablas : El nombre lógico de la tabla debe ser el siguiente, por ejemplo la tabla es TMEMPR Su nombre debería ser EMPRESA. Si la tabla es TTFACT_CAMB, su nombre debería ser TIPO CAMBIO Columna: El nombre lógico de la columna debe ser el siguiente, por ejemplo la columna es CO_OPRC. Su nombre debería ser CODIGO OPERACION. Nombres de Sistemas OFICONT : Contabilidad OFIINTE : Interface a Contabilidad OFILOGI : Logística OFIPLAN : Recursos Humanos OFISEGU : Seguridad OFITESO : Tesorería OFIVENT : Ventas MODELO - Asignar en el modelo el segmento de índice, data o temporal al que pertenezca el objeto. 108 - Incluir en el modelo temporales e índices creados para mejorar performance. 109 Anexo N° 6 - BASE DE DATOS (FISICO) Devices o Equivalentes : Sybase y Microsoft SqlServer 6.5 DVWSSSSN.XXX Donde : W = Data/ Log / Backup (D / L / B) SSSS = Sistema N = Correlativo (desde 1) XXX = Extensión (dat, log, dmp) Ejemplos : DVDCONT1.DAT (device de data) DVLCONT1.LOG (device de log) DVBCONT1.DMP (device de backup) Microsoft SqlServer 7 y 2000 DVWSSSSN.XXX Donde : W = Data/ Log / Backup (D / L / B) SSSS = Sistema N = Correlativo (desde 1) XXX = Extensión (mdf, ldf, dmp) Ejemplos : DVDCONT1.MDF (File de data) DVLCONT1.LDF (File de log) DVBCONT1.DMP (device de backup) Oracle DFWSSSSN.XXX Donde : W = Data/ Log / Indice / Temporal (D / L / I / T) SSSS = Sistema N = Correlativo (desde 1) XXX = Extensión (dat, log, idx, tmp) Ejemplos : DFDCONT1.DAT (Data file de data) 110 Segmentos o Equivalentes : Sybase y Microsoft SGWSSSSN Donde : W = Data (D) / Indice (I) SSSS = Sistema N = Correlativo (desde 1) Ejemplo : SGDCONT1 SGICONT1 Oracle TSWSSSSN Donde : W = Data / Temporal / Indice (D / T / I) SSSS = Sistema N = Correlativo (desde 1) Ejemplos : TSDCONT1 (Tablespace de data) TSTCONT1 (Tablespace de temporales) Base de Datos : OFI = Ofisis , SSSS = Sistema Ejemplos : OFIACTI : Activo Fijo OFICONT : Contabilidad OFIINTE : Interface a Contabilidad OFILOGI : Logística OFIMARK : Marketing OFIPLAN : Recursos Humanos OFIPRES : Presupuestos OFIPROD : Producción OFISEGU : Seguridad OFITESO : Tesorería OFIVENT : Ventas 111 Anexo N° 7 - STORED PROCEDURES Los nombres de los stored procedures deberán empezar con “SP_”, seguido por el nombre de la tabla, _X99 (X = I,D,Q,U ) , ( 99 = número correlativo). CABECERA DE SP´s Los SP de cualquier base de datos deberán empezar de la siguiente manera: Create Procedure SP_TXMVTO_CNTB_I01 /*----------------------------------------------------------------------------*/ /*----- Empresa : OFISIS S.A. -----*/ /*----- Cliente : OFISIS S.A. -----*/ /*----- Sistema : Contabilidad -----*/ /*----- Módulo : Empresa -----*/ /*----- Programa : Cierre de Fin de Año -----*/ /*----- Script : TXMVTO_CNTB -----*/ /*----- Nombre SP : SP_ TXMVTO_CNTB_I01 -----*/ /*----- Desarrollado por : Franco Gamboni Koifman -----*/ /*----- Fecha Creación : 10/03/2003 -----*/ /*----- Base Datos : Microsoft Sql Server -----*/ /*----- Versión : 2000 -----*/ /*----- Invoca a SP : SP_ TXMVTO_CNTB_I02 -----*/ /*-----------------------------------------------------------------------------*/ /*-----------------------------------------------------------------------------*/ /*----- Modificado 1 por : Paola del Carpio -----*/ /*----- Fecha Modificación : 13/03/2003 -----*/ /*----- Detalle Modificación: Se agregaron campos en el -----*/ /*----- insert -----*/ /*-----------------------------------------------------------------------------*/ /*----------------------------------------------------------------------------------*/ /*----- Modificado 2 por : Martín García -----*/ /*----- Fecha Modificación : 10/04/2003 -----*/ /*----- Detalle Modificación: Se corrigió error en el proceso -----*/ /*----------------------------------------------------------------------------------*/ /*-----------------------------------------------------------------------------*/ /*----- Modificado 3 por : Daniel Chiang -----*/ /*----- Fecha Modificación : 15/04/2003 -----*/ /*----- Detalle Modificación: Se agregaron campos en el -----*/ /*----- insert -----*/ /*-----------------------------------------------------------------------------*/ /*-----------------------------------------------------------------------------*/ /*----- Comentarios : -----*/ /*----- -----*/ /*----- -----*/ /*-----------------------------------------------------------------------------*/ /*-------------------------------------------------------------------------------------*/ 112 /*-- Drop Proc SP_ TXMVTO_CNTB_I01 --*/ /*-- Grant All On SP_ TXMVTO_CNTB_I01 To DESARROLLO --*/ /*-- SP_ TXMVTO_CNTB_I01 ‘01’, 1, 2002, 13, 2003, 0, 5 --*/ /*------------------------------------------------------------------------------------*/ Sólo las 3 últimas modificaciones. VARIABLES DE SP´s Los nombres de todas las variables deberán estar en mayúsculas y deberán estar asignadas a un dominio. En el caso de Oracle se le deberá de asignar a un campo de una tabla. Son de tres tipos : S : string N : numérico D : date (fecha) Variables de Ingreso (Input) : Empiezan con la letra “I”, seguida del tipo de dato. Sybase y Microsoft @ISCO_EMPR @INNU_ANNO @INNU_MESE Oracle e Informix ISCO_EMPR INNU_ANNO INNU_MESE Variables de Cursores : Empiezan con la letra “C”, seguida del tipo de dato. Sybase y Microsoft @CSCO_MONE @CDFE_DOCU @CNIM_TOTA Oracle e Informix CSCO_MONE CDFE_DOCU CNIM_TOTA Variables de Trabajo : Empiezan con la letra “V”, seguida del tipo de dato. Sybase y Microsoft @VSCO_EMPL @VDFE_DOCU @VNIM_TOTA 113 Oracle e Informix VSCO_EMPL VDFE_DOCU VNIM_TOTA Variables de Salida (Output) : Empiezan con la letra “O”, seguida del tipo de dato. Sybase y Microsoft @OSCO_EMPR @ONNU_ANNO @ONNU_MESE Oracle e Informix OSCO_EMPR ONNU_ANNO ONNU_MESE FINAL DE SP´s La parte final del stored procedure es la siguiente : /*---------------------------- Fin -----------------------------*/ MODIFICACION DE SP´s Cada vez que se actualice un stored procedure se deberá crear un nuevo bloque en la cabecera identificando la modificación : /*-----------------------------------------------------------------------------*/ /*----- Modificado # por : Paola del Carpio -----*/ /*----- Fecha Modificación : 15/03/2003 -----*/ /*----- Detalle Modificación: Se agregaron campos en el -----*/ /*----- insert -----*/ /*-----------------------------------------------------------------------------*/ OBSERVACIONES SOBRE SP´s - Los nombres de los cursores deberán tener el mismo formato que el stored procedure, a diferencia que en lugar de empezar con “SP” empezarán con “CU” y terminan con un correlativo. Ejemplo: CU_TXMVTO_CNTB_I01_1 - Cada proceso debe tener su propia cabecera. - Todas las sentencias Sql deberán empezar con mayúscula y el resto en minúscula. - Los nombres de las tablas y las columnas son en mayúsculas. - Todos los stored procedures deberán estarindentados y con comentarios. 114 INDENTACION DE SP’s Ejemplo de SP indentado : (Máximo 03 caracteres de indentación) Create Proc SP_TXMVTO_CNTB_I01 **************************************** ...... Cabecera y Comentarios **************************************** @ISCO_EMPR TD_CH_002, @INNU_ANNO TD_SI_004_ANNO, Declare @VSCO_MONE TD_CH_002, @VSCO_UNID_CNTB TD_SI_004_ANNO, @VNNU_MESE TD_SI_004_ANNO, While Begin If @VNNU_MESE = 1 Begin Select ...... End End Return 115 Anexo N° 8 - PROGRAMA CLIENTE (APT) Se DEBE trabajar con APT en NO en APP. Este cambio hace que los programas se corrompan menos y además ocupan menos espacio. NOMBRE DE APT El APT se deberá llamar de la siguiente manera : SSMM0001.APT -> donde : SS -> Sistema MM -> Módulo SS Identifica el sistema ( Ejemplo de SS : AC = Activo Fijo, CO = Contabilidad, LO = Logística, PL = Recursos Humanos, SE = Seguridad, PR = Presupuestos, TE = Tesorería VE = Ventas ) MM Identifica el módulo ( Ejemplo : AD = Administración, CO = Corporación, EM = Empresa ) CABECERA DE APT La cabecera de todos los programas cliente (APTs) deberá tener lo siguiente : /*-----------------------------------------------------------------------------*/ /*----- Empresa : OFISIS S.A. -----*/ /*----- Cliente : OFISIS S.A. -----*/ /*----- Sistema : Contabilidad -----*/ /*----- Módulo : Empresa -----*/ /*----- Nombre Programa: COEM0001 -----*/ /*----- Desarrollado por : Franco Gamboni Koifman -----*/ /*----- Fecha Creación : 28/08/2003 -----*/ /*----- -----*/ /*----- Base Datos : Microsoft Sql Server -----*/ /*----- Versión BD : 2000 -----*/ /*----- Herramienta : Centura -----*/ /*----- Versión Herram. : 2000 -----*/ /*----- Versión PTF: 3 -----*/ /*-----------------------------------------------------------------------------*/ /*-----------------------------------------------------------------------------*/ /*----- Modificado por : Maria Laura Uribe -----*/ /*----- Fecha Modificación : 30/08/2003 -----*/ /*----- Detalle Modificación: Reporte nuevo de Balance -----*/ /*-----------------------------------------------------------------------------*/ MODIFICACION DE APT 116 Cada vez que se actualice un APT se deberá de actualizar los siguientes datos en la cabecera (sólo con la última modificación) : /*------------------------------------------------------------------------------*/ /*----- Modificado por : Paola del Carpio -----*/ /*----- Fecha Modificación : 03/09/2003 -----*/ /*----- Detalle Modificación: Reporte nuevo de Balance -----*/ /*------------------------------------------------------------------------------*/ PRESENTACION EN APT Colores de las Letras en Pantalla : Negro : Fondo de color estándar del texto editable. Rojo : Fondo de color del texto cuando el dato es no editable. Azul : Fondo de color del texto editable cuando el dato tiene ayuda. Colores de Registros en Child Tables : Rojo : Registros Anulados, eliminados Tipo y Tamaño de Letra en Pantalla : Arial de 9 Normal Nota : Al Prototipear usar los Objetos Definidos en la Clase, no cambiar propiedades VARIABLES EN APT En el MDI debe haber una sola variable “booleana” para el control de las opciones. Las variables en los APT deberán estar en mayúsculas y deben empezar con su tipo de dato. Ejemplo : sCO_EMPR dFE_SIST ESTANDARES DE PRESENTACION ( APT ) Fechas Formato : dd/mm/yyyy En TODOS los programas (pantallas, reportes, tablas, etc.) Nota : NO es permitido cambiar atributos ( ninguno de ellos ) del objeto definido en la Clase Años Formato : yyyy En TODOS los programas (pantallas, reportes, tablas, etc.) Montos Formato : ...999,999,999.99... Alinear a la derecha (crearlo en la B.D. con tipo de dato) Tener cuidado con el tamaño de los montos (# de dígitos) y el número de decimales en los QRPS, sobre todo en los totales. Mínimo : 99,999,999.99 para los detalles (registros) 999,999,999.99 para los totales 117 Tipo de Letra Pantallas : Arial de 9 Reportes : Título : Arial de 11 Detalle : Arial de 9 (si es necesario, bajar a 7) Color utilizados en las Pantallas : - Negro : data fields editables, título de group box - Rojo : texto de data fields no editables - Azul : texto de data fields con ayuda 118 Anexo N° 9 - REPORTES ESTANDAR FORMATO HOJA TAMAÑO DE HOJA Los reportes Estándares deben respetar esta configuración de página, manipularemos estos datos sólo en casos específicos, por ejemplo si necesitamos el Reporte en Landscape u otro tamaño de hoja esto en coordinación con el Jefe de Proyecto. Si se van a imprimir reportes en matriciales y necesitamos que entren indistintamente en Carta o A4 debemos seleccionar Paper Style Custom y los siguientes datos : Portrait : Width : 20.975 Height : 27.95 Landscape : Width : 27.95 Height : 20.975 Tamaño de papel A4 y Carta (para impresoras matriciales) Landscape : 119 Siguientes Páginas: Observaciones al Reporte 120 (1) Arial 11 Negrita Centrado. Todo en Mayúsculas. (2) Arial 9 Negrita Alineado a la Izquierda, debe empezar en la Posición 0.2 del Reporte. (3) Arial 9 Negrita Centrado, se considera complemento aquella consideración que el usuario debe conocer para interpretar el Reporte : “Expresado en Nuevos Soles”. Todo en Mayúsculas. Si un Reporte NO va a usar el comentario opcional esta línea debe ser usada por las selecciones. (4) Arial 9 Negrita, el Título Alineado a la Izquierda y debe decir Pag. 9999, donde 9999 debe estar alineado a la derecha, es un entero de cuatro dígitos siempre mostrar los cuatro dígitos : 0001, 0999, 1000. (5) Arial 9 Negrita Alineado a la Izquierda, Nombre del Usuario conectado en el Sistema, (6) Arial 9 la cadena debe estar Alineada a la Izquierda NO necesariamente centrada en la Hoja pero sí alineada con las otras cadenas de Selección. Todo en Mayúsculas. Se debe tomar en cuenta que después de cada Título de Selección deben ir dos puntos, y que todos los Detalles de lo Seleccionado deben estar alineados ( Ver Ejemplo ). Colocar TODAS Las Selecciones y Ordenamientos fijos que se encuentren en la Pantalla de donde se genera el Reporte, se tienen dos opciones que se deben aplicar según criterio de la Persona que valida el Reporte ( Jefe o Gerente de Proyecto/Producto ) : a. Colocar sólo una Selección Por Línea. b. Colocar más de una Selección en una Línea. (7) Arial 9 Negrita Alineado a la Izquierda, Se colocará solamente la fecha en formato dd/mm/yyyy. (8) Arial 9 Negrita Alineado a la Izquierda, Nombre de QRP sin considerar extensión. (9) Arial 9 Negrita Alineado a la Izquierda, Se colocará solamente la hora en formato de 24 horas hh:mm:ss. (10) Arial 9 Alineado a la Izquierda, Todo en Mayúsculas, inmediatamente después terminar la impresión de las selecciones de la Pantalla se deben colocar 15 líneas en Blanco, reservadas para la opción de Filtro Tabla, en la configuración del Reporte colocar que si la cadena es vacía no se muestre la línea, tomar en cuenta que si en la tabla se ha configurado para que aparezca una cantidad n de opciones, entonces se deben pintar n líneas aquellas que no tengan selección deberá colocarse con la palabra TODOS. Estas cadenas de Selección Dinámica deben estar alineadas con la selección previa y de igual manera se debe tomar en cuenta que después de cada Título de Selección deben ir dos puntos, y que todos los Detalles de lo Seleccionado deben estar alineados ( Ver Ejemplo ). Respetar los Siguientes Estándares : Caso Rango : En el Reporte debe decir : CRITERIO RANGO DESDE AAA HASTA BBB Caso Selección : En el Reporte debe decir : CRITERIO SELECCI{ON Caso Similar : En el Reporte debe decir : CRITERIO SIMIILAR Caso No seleccione Nada : En el Reporte debe decir : CRITERIO TODOS (11) Títulos Columnas : Arial 9 Negrita Centrado ( cada título ), Todo en Mayúsculas. En este caso se disponen de dos Líneas para colocar los títulos, estas dos líneas deben tener marco ( la primera línea marco superior, la segunda línea marco inferior ). a. Los Títulos deben ser descriptivos. b. Todos los Títulos deben usar la línea inferior, si no es suficiente se usarán las dos líneas. c. Si se tienen casos en los que se debe colocar dos Títulos en la misma columna estos se deben separar por el Símbolo “/” . (12) Arial 9 Negrita Alineado a la Izquierda, Todo en Mayúsculas. Los Títulos de los Quiebres deben colocarse siguiendo el Formato : QUIEBRE : Código - Descripción_de_Quiebre. Por Ejemplo si tenemos un quiebre por Cuenta Contable el título debe ser : CUENTA CONTABLE : 10 – Caja y Bancos. Cada Título de Quiebre debe ser colocado dejando una pequeña sangría con respecto al Quiebre inmediato superior, el espacio de Sangría debe ser tres letras ( tomando como referencia el inicio del Título de Quiebre inmediatamente superior ). (13) Detalle : Arial 9. Seguir los siguientes criterios : 121 Tipo Dato Presentación Alineación Cadena Izquierda Fecha Centrado Número Decimales (*) 99’999,999 Derecha 999’999,999 ( totales ) Número Entero 99’999,999.99 Derecha 999’999,999.99 ( totales ) (*) Algunos reportes usan más de dos decimales tomar en cuenta esta particularidad (14) Arial 9 Negrita Alineado a la Izquierda, Todo en Mayúsculas. Los títulos de Totales de los Quiebres deben estar alineados con su respectivo título de quiebre, los Títulos deben seguir el siguiente formato : TOTAL CÓDIGO – DESCRIPCIÓN : . Por Ejemplo si tenemos un quiebre por Cuenta Contable el título del Total debe ser : TOTAL 10 – CAJA Y BANCOS : (15) Arial 9 Alineado a la derecha, Todo en Mayúsculas. En el caso de los SubTotales deben soportar 999’999,999 ( en el caso de enteros ) y 999’999,999.99 ( en el caso de decimales ), los Totales Parciales deben estar perfectamente alineados en sus respectivas columnas y adicionalmente deben tener el borde superior con una línea. Antes del Importe se debe colocar el Símbolo de la Moneda. (16) Arial 9 el Título alineado a la izquierda, Todo en Mayúsculas, como muestra el gráfico superior, los importes deben soportar 999’999,999 ( en el caso de enteros ) y 999’999,999.99 ( en el caso de decimales ), los Totales deben estar perfectamente alineados en sus respectivas columnas y adicionalmente deben tener el borde superior con una línea. Antes del Importe se debe colocar el Símbolo de la Moneda. (17) Fin de Reporte. (18) Total Resultado de un conteo de Registros Por Ejemplo : TOTAL GENERAL TRABAJADORES. (19) Línea en Blanco que debe tener el Tamaño de un Background de 6 ( En general las líneas en Blanco deben tener este ancho ). Tomar en cuenta que salvo los datos de la Cabecera del Reporte (sin incluir los títulos del detalle) todos los demás datos pueden variar su tamaño dependiendo de la necesidad del Reporte. A Partir de la Segunda Página se imprime tal y como indica el modelo adjunto. Sólo los Reportes Oficiales podrán tener un Formato diferente al Presentado. Cuando se realice un Nuevo Reporte Adicional para un Cliente debe usarse este Formato salvo se indique lo contrario. Todo Reporte de Sistema Estándar debe respetar este Formato. 122 ANEXO 10 – PLAN DE PRUEBAS PLAN DE PRUEBAS - TESTING Cliente_______NEPTUNIA________________________ Fecha Test _20/10/2015__ Título del Requerimiento: Nro. Sec:_001_ _________Reporte Procesos FWD y Reporte Procesos FWD2______________________ Alcance Funcional: AT-Neptunia_00003871 Trabajo realizado en: OFISIS[X] Cliente [ ] INFORMACION DE PLATAFORMA Herramienta Utilizada: CENTURA…………………….…………..… .NET………..……………..…………..…… REPORTING SERVICE Base de Datos SQL Server ______ ORACLE ______ Otro ____________ ______ Nombre del servidor: __________________________________________________________ Ambiente: Test [] fecha de restauración: _/_/_ Producción [ X ] Sistema Operativo (Servidor) Sistema Operativo (PC) Versión Versión Windows Server 2012 Windows 8 Windows Server 2008 Windows Vista Linux _________ Windows XP Unix _________ ______________ _________ ______________ _________ Microsoft Office: versión _______ español [] inglés [ ] Usuario de Prueba: Código __OFISIS _______________________________________________ 123 REVISION de ITEMS Y SUB-ITEMS NRO OPCION PROB APRO ITEM ADO BADO 1 2 3 4 SEGUIMIENTO: OFISIS - DESARROLLO OFISIS – ANALISIS/TEST ALTER- FECHA TIEMPO FECHA APROBADO DESARROLLADO POR REVISADO POR NATIVA ENTREGA INVERTIDO TERMINO S/N 1 Ronald Trigueros A 20/10/2015 Percy García 20/10/2015 N 2 3 124 ENTREGA Anexo 11 - Alcance Funcional Cliente: Q.P.R. S.A.C. (Quality Products) Proyecto / Alcance: Q.P.R. – Liquidación de Cobranzas Código trabajo CRM: 00003807 Tipo de servicio: Venta Actualización Versión Adicional 1 Requerimientos levantados 1.1 Requerimientos funcionales Código Descripción RF-001 Liquidar Cobranza de Clientes 1.2 Requerimientos no funcionales Código Descripción RNF-nn RNF-nn 2 Matriz de trazabilidad Req. Func. Descripción del Requisito Funcional RF-001 Liquidar Cobranza de Clientes X 3 Reglas del Negocio Regla Descripción de la Regla de Negocio Negocio RN-nnn RN-nnn 4 Diagrama de Casos de Uso 125 CU_QPR_001 5 Descripción de Actores Actor: Asesor de Ventas Actor Liquidador Identificador: AC-001 Descripción Colaborador que realiza la liquidación de cobranzas de los repartos entregados al cliente. Características Comentarios 6 Especificación de Casos de Uso Caso de Uso: Registrar Liquidación de Cobranzas Caso de Uso Registrar Liquidación de Cobranzas Identificador: CU_QRP_001 Actores Asesor de ventas Descripción La liquidación de cobranza con el Courier es realizada por la encargada de caja, quien revisa por Courier todos los pedidos despachados en base al número de facturas que han sido entregados a cliente y se liquida ingresando por cada comprobante el medio de pago realizado (por defecto debe mostrarse el medio de pago del pedido de venta especificado, con posibilidad de poder modificar el detalle y registrarlo de acuerdo a lo realizado físicamente en la entrega al cliente), aquí ya no aparecen los pedidos devueltos liquidados por el jefe de distribución. El sistema ya valoriza los pedidos entregado por forma de pago y el total de todos los pedidos entregados. Referencias Precondición Existan Transportistas (Courier) Existan Confirmación de entrega al Cliente registrados (Módulo Gestión de Repartos). Postcondición Cobranza registrada Módulo OFISIS ERP FLUJO PRINCIPAL Nro. Acción del actor Acción del sistema 1 Usuario ingresa a pantalla en donde Muestra pantalla. liquidara masivamente las facturas Ver Nota: 1. Datos que debe mostrar pantalla asociadas a una confirmación de entrega. 2 Ingresa Datos de: Muestra datos ingresados por el usuario  Fecha Ver Flujo Alterno: 1. Usuario ingresa descuento  Seleccionar Courier (Transportista)  Seleccionar Confirmación de entrega al Cliente. 3 Lista Carga 4 3 Graba facturación Internamente el sistema debe realizar lo siguiente: - Realizar un movimiento de almacén de salida de las partes de los componentes del kit. - Realizar un movimiento de almacén de ingreso por el producto final (kit). - Realiza un movimiento de salida por la venta. Validación: 1. Verificar que los componentes del kit tengan stock disponible. 4 Imprime documento de venta Imprime Documento de venta. FLUJOS ALTERNOS Flujo Alterno: 1. Usuario ingresa descuento Nro.F.P. Descripción de acciones alternas 3 El usuario ingresa descuento en caso lo requiera. 126 VALIDACIONES Validación: 1. Verificar que los componentes del kit tengan stock disponible Nro. Descripción de la validación 1 En caso no cuenta con stock disponible en uno de los componentes debe mostrar alerta de “No cuenta con Stock en uno de los componentes del kit”. NOTAS Nro. Descripción 1 Datos que debe mostrar pantalla:  Fecha.  Courier (Transportista)  Comprobante de Confirmación de entrega del cliente 127