UNIVERSIDAD DON BOSCO VICERRECTORÍA ACADÉMICA FACULTAD DE INGENIERÍA TRABAJO DE GRADUACIÓN PARA OPTAR AL GRADO DE: Maestro en Arquitectura de Software PROYECTO: Manual para la implementación de CMMI a nivel de capacidad 2 con SCRUM en el área de desarrollo de software. PRESENTADO POR: Nelson Mauricio García López Jimmy Henry Linares Valencia ASESOR: Dr. Joaquín Ernesto Aparicio Hernández Antiguo Cuscatlán, La Libertad, El Salvador, Centro América Febrero 2020 1 DEDICATORIA La presente tesis se la dedico a Dios todo poderoso por haberme provisto de la fortaleza, templanza y constancia para realizar esta tesis. A mis padres Jorge Alberto García Mejía y Rosa Margarita López de García, por brindarme su apoyo incondicional para realizar esta aventura. A mi familia, mi hermosa familia que en todo momento me brindó su comprensión y el tiempo para realizar este proyecto. 2 DEDICATORIA Esta tesis está dedicada a Dios, porque me brindó todo aquello que mi espíritu necesitaba, para concluir esta meta en la que me embarqué, él conoce lo que representa para mí. A mi madre y hermanas que incentivaron este esfuerzo con palabras de aliento, para que no desistiera del reto que había elegido, recordándome que creían en mí. A mi amada familia, quien me dio su apoyo incondicional en esta etapa, en mis momentos de flaqueza, siempre estuvieron a mi lado motivándome y dándome su amor. 3 AGRADECIMIENTOS Agradezco a Dios todo poderoso por permitir llevar a buen término esta investigación facilitando el contacto con los diferentes maestros, catedráticos y compañeros quienes proveyeron diferentes herramientas y en especial acrecentaron la llama por la investigación científica. Agradezco el apoyo de nuestro asesor el Dr. Joaquín Aparicio que bajo su orientación se elaboró un trabajo que servirá de referencia para las personas que deseen incursionar en el mundo de CMMI y SCRUM. 4 AGRADECIMIENTOS Agradezco a Dios, que me permitió llegar a este punto de culminación de mi carrera, porque sin su bendición no lo hubiera logrado. Agradezco a la universidad quien me brindó las herramientas para poder hacerle frente a este proyecto, a mi asesor por sus palabras de ánimo y orientación, las cuales fueron claves para esta investigación, agradezco a mi madre y hnas. que siempre me transmitieron ese deseo de superarme, que me impulsaron a siempre tratar de ir más lejos cada día, a mi amada familia quienes fueron el motor principal para culminar este trabajo, su apoyo en los momentos difíciles fue vital para mí, jamás podré devolver todo lo que me han dado. 5 RESUMEN Se realizó una investigación cuyo propósito es establecer el nivel de capacidad 2 de CMMI con SCRUM. Para realizar el presente trabajo se procedió a investigar el marco teórico de CMMI de desarrollo versión 1.3 y SCRUM, así como también artículos científicos que abordasen la implementación de CMMI y SCRUM en diferentes niveles de capacidad, actividades específicas de SCRUM y diferente bibliografía sobre SCRUM y CMMI, con lo cual se identificó los productos esperados de CMMI y la forma en que se podrían obtener a través de las diferentes actividades de SCRUM, facilitando de esta forma llegar a nivel de capacidad 2 según CMMI. Con lo anterior se obtuvo una matriz de convergencia la cual permite establecer en que actividades de SCRUM los productos esperados de CMMI en las áreas de proceso, la cual fue sometida a consideración en las áreas de tecnología en empresas, una privada y una del sector público para obtener sus apreciaciones sobre la misma. Se concluye que para poder llevar unos procesos a nivel de capacidad dos de CMMI, la dirección de la empresa debe estar comprometida con el cambio para que todo el personal de base se alinea a la directriz dada. 6 7 ÍNDICE CAPÍTULO I: INTRODUCCIÓN ..................................................................................... 19 1.1 DESCRIPCIÓN DEL PROBLEMA ....................................................................... 19 1.2 PLANTEAMIENTO DEL PROBLEMA ............................................................... 21 1.3 TIPO INVESTIGACIÓN........................................................................................ 22 1.4 METODOLOGÍA ................................................................................................... 22 1.4.1 CRITERIO DE CLASIFICACIÓN ENFOQUE ............................................. 22 1.4.2 MIXTO ............................................................................................................ 22 1.4.3 CRITERIO DE CLASIFICACIÓN DE ALCANCE ....................................... 22 1.4.3.1 DESCRIPTIVO ........................................................................................... 22 1.4.4 UNIDAD DE ANÁLISIS ................................................................................ 23 1.4.5 VARIABLES ................................................................................................... 23 1.4.5.1 VARIABLES Y SU MEDICIÓN ............................................................... 24 1.4.6 TÉCNICA E INSTRUMENTOS..................................................................... 24 1.4.7 PROCEDIMIENTOS Y ANÁLISIS ............................................................... 26 1.4.7.1 INSTRUMENTOS A UTILIZAR POR OBJETIVO.................................. 26 CAPÍTULO II: ANTECEDENTES ................................................................................... 29 2.1 OBJETIVOS ........................................................................................................... 29 2.1.1 GENERALES .................................................................................................. 29 2.1.2 ESPECÍFICOS................................................................................................. 29 2.2 JUSTIFICACIÓN ................................................................................................... 29 2.3 ALCANCES Y LÍMITES ....................................................................................... 30 2.3.1 ALCANCES .................................................................................................... 30 2.3.2 LIMITACIONES ............................................................................................. 30 CAPÍTULO III: ESTADO DEL ARTE ............................................................................. 31 3.1 CMMI ..................................................................................................................... 34 3.1.1 ÁREAS DE PROCESO PARA LA ELABORACIÓN DEL MANUAL ........ 39 8 3.1.1.1 GESTIÓN DE REQUISITOS (REQM) ...................................................... 39 3.1.1.2 GESTIÓN DE RIESGOS (RSKM)............................................................. 43 3.1.1.3 DESARROLLO DE REQUISITOS (RD) .................................................. 48 3.1.1.4 VERIFICACIÓN (VER) ............................................................................. 58 3.1.1.5 VALIDACIÓN (VAL) ................................................................................ 64 3.1.1.6 SOLUCIÓN TÉCNICA (TS) ...................................................................... 69 3.1.1.7 INTEGRACIÓN DEL PRODUCTO (PI) ................................................... 77 3.1.1.8 PLANIFICACIÓN DEL PROYECTO (PP) ............................................... 84 3.1.1.9 GESTIÓN INTEGRADA DEL PROYECTO (IPM).................................. 95 3.1.1.10 MONITORIZACIÓN Y CONTROL DEL PROYECTO (PMC) ........... 103 3.1.1.11 GESTIÓN DE CONFIGURACIÓN (CM) ............................................. 108 3.1.1.12 ASEGURAMIENTO DE LA CALIDAD DEL PROCESO Y DEL PRODUCTO (PPQA) ..................................................................................................... 114 3.2 SCRUM................................................................................................................. 118 3.2.1 FASE DE INICIO .......................................................................................... 120 3.2.1.1 CREACIÓN DE LA VISIÓN DEL PROYECTO .................................... 121 3.2.1.2 IDENTIFICAR AL SCRUM MASTER Y PARTNERS .......................... 122 3.2.1.3 FORMACIÓN DE UN SCRUM TEAM (EQUIPO SCRUM) ................. 122 3.2.1.4 DESARROLLO DE EPICS (EPOPEYA) ................................................ 123 3.2.1.5 CREACIÓN DEL PRODUCT BACKLOG PRIORIZADA .................... 124 3.2.1.6 REALIZAR EL PLAN DE LANZAMIENTO ......................................... 125 3.2.2 PLANEAR Y ESTIMAR .............................................................................. 126 3.2.2.1 ELABORAR USER STORIES (HISTORIAS DE USUARIO) ............... 126 3.2.2.2 APROBAR, ESTIMAR Y ASIGNAR USER STORIES ......................... 127 3.2.2.3 ELABORACIÓN DE TAREAS ............................................................... 129 3.2.2.4 ESTIMAR TAREAS................................................................................. 131 3.2.2.5 ELABORACIÓN DEL SPRINT BACKLOG (PILA DE PRODUCTOS DEL SPRINT) 132 3.2.3 IMPLEMENTAR .......................................................................................... 133 9 3.2.3.1 CREAR ENTREGABLES ........................................................................ 133 3.2.3.2 LLEVAR A CABO LAS REUNIONES DIARIAS ................................. 135 3.2.3.3 MANTENIMIENTO DEL PRODUCT BACKLOG PRIORIZADO ....... 136 3.2.4 REVISIÓN Y RETROSPECTIVA ............................................................... 137 3.2.4.1 CONVOCAR SCRUM DE SCRUMS ...................................................... 137 3.2.4.2 DEMOSTRACIÓN Y VALIDACIÓN DEL SPRINT ............................. 138 3.2.4.3 SPRINT RETROESPECTIVE (RETROSPECTIVA DE SPRINT) ......... 140 3.2.5 LANZAMIENTO .......................................................................................... 141 3.2.5.1 ENVÍO DE ENTREGABLES .................................................................. 141 3.2.5.2 RETROSPECTIVA DEL PROYECTO.................................................... 142 CAPÍTULO IV: VALIDACIÓN DE LA PROPUESTA ................................................. 145 4.1 MANUAL DE APLICACIÓN PARA COMBINAR SCRUM Y CMMI ............ 145 4.1.1 GESTIÓN DE REQUISITOS (REQM) ........................................................ 145 4.1.1.1 META ESPECÍFICA 1: GESTIONAR LOS REQUISITOS ................... 145 4.1.2 GESTIÓN DE RIESGOS (RSKM) ............................................................... 148 4.1.2.1 META ESPECÍFICA 1: PREPARAR LA GESTIÓN DE RIESGOS ...... 148 4.1.2.2 META ESPECÍFICA 2: IDENTIFICAR Y ANALIZAR LOS RIESGOS 151 4.1.2.3 META ESPECÍFICA 3: MITIGAR LOS RIESGOS ............................... 152 4.1.3 DESARROLLO DE REQUISITOS (RD) ..................................................... 154 4.1.3.1 META ESPECÍFICA 1: DESARROLLAR LOS REQUISITOS DE CLIENTE 154 4.1.3.2 META ESPECÍFICA 2: DESARROLLAR LOS REQUISITOS DE PRODUCTO 156 4.1.3.3 META ESPECÍFICA 3: ANALIZAR Y VALIDAR LOS REQUISITOS157 4.1.4 VERIFICACIÓN (VER) ............................................................................... 160 4.1.4.1 META ESPECÍFICA 1: PREPARAR LA VERIFICACIÓN ................... 160 10 4.1.4.2 META ESPECÍFICA 2: REALIZAR LAS REVISIONES ENTRE PARES 161 4.1.4.3 META ESPECÍFICA 3: VERIFICAR LOS PRODUCTOS DE TRABAJO SELECCIONADOS ........................................................................................................ 163 4.1.5 VALIDACIÓN (VAL) .................................................................................. 164 4.1.5.1 META ESPECÍFICA 1: PREPARAR LA VALIDACIÓN ...................... 164 4.1.5.2 META ESPECÍFICA 2: VALIDAR EL PRODUCTO O LOS COMPONENTES DE PRODUCTO .............................................................................. 165 4.1.6 SOLUCIÓN TÉCNICA (TS) ........................................................................ 166 4.1.6.1 META ESPECÍFICA 1: SELECCIONAR SOLUCIONES DE COMPONENTES DE PRODUCTO .............................................................................. 166 4.1.6.2 META ESPECÍFICA 2: DESARROLLAR EL DISEÑO ........................ 167 4.1.6.3 META ESPECÍFICA 3: IMPLEMENTAR EL DISEÑO DEL PRODUCTO 168 4.1.7 INTEGRACIÓN DEL PRODUCTO (PI) ..................................................... 169 4.1.7.1 META ESPECÍFICA 1: PREPARARSE PARA LA INTEGRACIÓN DEL PRODUCTO 169 4.1.7.2 META ESPECÍFICA 2: ASEGURAR LA COMPATIBILIDAD DE LAS INTERFACES ................................................................................................................ 170 4.1.7.3 META ESPECÍFICA 3: ENSAMBLAR LOS COMPONENTES DE PRODUCTO Y ENTREGAR EL PRODUCTO ............................................................ 171 4.1.8 PLANIFICACIÓN DEL PROYECTO (PP).................................................. 173 4.1.8.1 META ESPECÍFICA 1: ESTABLECER LAS ESTIMACIONES........... 173 4.1.8.2 META ESPECÍFICA 2: DESARROLLAR UN PLAN DE PROYECTO 175 4.1.8.3 META ESPECÍFICA 3: OBTENER EL COMPROMISO CON EL PLAN 181 4.1.9 GESTIÓN INTEGRADA DEL PROYECTO (IPM) .................................... 182 4.1.9.1 META ESPECÍFICA 1: UTILIZAR EL PROCESO DEFINIDO DEL PROYECTO 182 11 4.1.9.2 META ESPECÍFICA 2: COORDINAR Y COLABORAR CON LAS PARTES INTERESADAS RELEVANTES................................................................... 184 4.1.10 MONITORIZACIÓN Y CONTROL DEL PROYECTO (PMC) ................. 185 4.1.10.1 META ESPECÍFICA 1: MONITORIZAR EL PROYECTO FRENTE AL PLAN 185 4.1.10.2 META ESPECÍFICA 2: GESTIONAR LAS ACCIONES CORRECTIVAS HASTA SU CIERRE ...................................................................................................... 188 4.1.11 GESTIÓN DE CONFIGURACIÓN (CM) .................................................... 189 4.1.11.1 META ESPECÍFICA 1: ESTABLECER LAS LÍNEAS BASE ............ 189 4.1.11.2 META ESPECÍFICA 2: SEGUIR Y CONTROLAR LOS CAMBIOS . 190 4.1.11.3 META ESPECÍFICA 3: ESTABLECER LA INTEGRIDAD ............... 190 4.1.12 ASEGURAMIENTO DE LA CALIDAD DEL PROCESO Y DEL PRODUCTO (PPQA) ......................................................................................................... 191 4.1.12.1 META ESPECÍFICA 1: EVALUAR OBJETIVAMENTE LOS PROCESOS Y LOS PRODUCTOS DE TRABAJO ...................................................... 191 4.1.12.2 META ESPECÍFICA 2: PROPORCIONAR UNA VISIÓN OBJETIVA 192 CAPÍTULO V: CONCLUSIÓN ...................................................................................... 195 5.1 TRABAJOS FUTUROS ....................................................................................... 196 ANEXOS ......................................................................................................................... 197 6.1 MATRIZ DE SELECCIÓN DE DOCUMENTACIÓN DE CMMI ..................... 197 6.2 MATRIZ DE SELECCIÓN DE DOCUMENTACIÓN DE SCRUM .................. 215 6.3 MATRIZ DE CONVERGENCIA DE CMMI Y SCRUM ................................... 229 6.4 ENTREVISTA ...................................................................................................... 271 BIBLIOGRAFÍA ............................................................................................................. 275 12 ÍNDICE DE FIGURAS Figura 2.3.1 Factores que afecta la adopción de SCRUM (Hanslo, Mnkandla, & Vahed, 2019) ....................................................................................................................................................... 31 Figura 2.3.2 Los cinco niveles del modelo de madurez de capacidades (Lina & Dan, 2012). ....................................................................................................................................................... 32 Figura 3.2.1 Fases y procesos de SCRUM .......................................................................... 120 Figura 3.2.2 Tablero SCRUM (Satpathy, 2013). ................................................................. 134 Figura 4.1.1 Categorías y subcategorías de riesgos del proyecto (Goicochea, 2012). ........ 149 Figura 4.1.2 Resumen de responsabilidades del equipo SCRUM (Satpathy, 2013) ........... 151 Figura 4.1.3 Gráfica de riesgo quemado (Satpathy, 2013). ................................................. 154 Figura 4.1.4 Ciclo de vida del software basado en SCRUM y CMMI (Parte 1). ................ 193 Figura 4.1.5 Ciclo de vida del software basado en SCRUM y CMMI (Parte 2). ................ 194 13 INDICE DE TABLAS Tabla 1.4.1 Objetivos específicos y unidad de análisis. ........................................................ 23 Tabla 1.4.2 Unidad de análisis y variables. ........................................................................... 23 Tabla 1.4.3 Variable, técnica e instrumento. ......................................................................... 26 Tabla 3.1.1 Niveles de CMMI. (Carnegie Mellon University, 2010) .................................... 34 Tabla 3.1.2 Estructura de Áreas de proceso. (Carnegie Mellon University, 2010) ............... 37 Tabla 3.2.1 Entradas, herramientas y salidas del proceso crear la visión del proyecto. ...... 121 Tabla 3.2.2 Entradas, herramientas y salidas del proceso identificar al SCRUM master y al socio(s). ....................................................................................................................................... 122 Tabla 3.2.3 Entradas, herramientas y salidas del proceso formación de un equipo SCRUM. ..................................................................................................................................................... 123 Tabla 3.2.4 Entradas, herramientas y salidas del proceso desarrollo de épica(s). ............... 124 Tabla 3.2.5 Entradas, herramientas y salidas del proceso creación de la lista priorizada de pendientes del producto. ............................................................................................................. 125 Tabla 3.2.6 Entradas, herramientas y salidas del proceso realización del plan de lanzamiento. ..................................................................................................................................................... 126 Tabla 3.2.7 Entradas, herramientas y salidas del proceso elaborar historias de usuario. .... 127 Tabla 3.2.8 Entradas, herramientas y salidas del proceso aprobar, estimar y asignar historias de usuarios. ................................................................................................................................. 129 Tabla 3.2.9 Entradas, herramientas y salidas del proceso elaboración de tareas. ................ 130 Tabla 3.2.10 Entradas, herramientas y salidas del proceso estimar tareas. ......................... 132 Tabla 3.2.11 Entradas, herramientas y salidas del proceso elaboración de la lista de pendientes del sprint...................................................................................................................................... 133 Tabla 3.2.12 Entradas, herramientas y salidas del proceso crear entregables. .................... 134 Tabla 3.2.13 Entradas, herramientas y salidas del proceso llevar a cabo el Stand-up diario. ..................................................................................................................................................... 136 Tabla 3.2.14 Entradas, herramientas y salidas del proceso mantenimiento de la lista priorizada de pendientes del producto.......................................................................................................... 136 Tabla 3.2.15 Entradas, herramientas y salidas del proceso convocar SCRUM de SCRUMs. ..................................................................................................................................................... 138 14 Tabla 3.2.16 Entradas, herramientas y salidas del proceso demostración y validación del sprint. .......................................................................................................................................... 139 Tabla 3.2.17 Entradas, herramientas y salidas del proceso retrospectiva de sprint. ............ 140 Tabla 3.2.18 Entradas, herramientas y salidas del proceso envío de entregables. .............. 142 Tabla 3.2.19 Entradas, herramientas y salidas del proceso retrospectiva del proyecto. ...... 142 Tabla 6.1.1 Matriz de selección de documentación de CMMI. ........................................... 213 Tabla 6.2.1 Matriz de selección de documentación de SCRUM. ........................................ 227 Tabla 6.3.1 Matriz de selección de documentación de SCRUM. ........................................ 270 Tabla 6.4.1 Entrevista. ......................................................................................................... 271 15 ACRÓNIMOS ACRÓNIMO SIGNIFICADO PMC Project monitoring and control / Monitorización y control del proyecto PP Project planning / Planificación del proyecto REQM Requirements management / Gestión de requisitos CM Configuration management / Gestión de configuración PI Product integration / Integración del producto RSKM Risk management / Gestión de riesgos DoD Definition of done / Definición de terminado PO Product owner / Dueño del producto PBI Product backlog item / Ítem de la pila de producto INVEST Independent-negotiable-valuable-estimable-small-testable Independientes-negociables-valorables-estimables-reducidas-testables SMART Specific-measurable-achievable-relevant-time-bound Específico-medible-lograble-relevante-tiempo límite SOS SCRUM of SCRUMs meeting / Reunión de SCRUM de SCRUMs SWOT Strengths-weaknesses-opportunities-threats Fortalezas debilidades oportunidades amenazas FODA Fortalezas oportunidades debilidades amenazas JAD Joint application design / Diseño de aplicación conjunta SGB The SCRUM guidance body / Cuerpo de asesoramiento de SCRUM CCC Card-conversation-confirmation / Tarjeta-conversación-confirmación EMV Expected monetary value / Valor monetario esperado RBS Risk breakdown structure / Estructura de desglose de riesgos 16 ACRÓNIMO SIGNIFICADO WBS Work breakdown structure / Estructura de desglose de trabajo CAR Causal Analysis and Resolution / Análisis causal y resolución CM Configuration Management / Gestión de configuración DAR Decision Analysis and Resolution / Análisis de decisiones y resolución IPM Integrated Project Management / Gestión integrada del Proyecto MA Measurement and Analysis / Medición y análisis OPD Organizational Process Definition / Definición de Procesos de la organización OPF Organizational Process Focus / Enfoque en Procesos de la organización OPM Organizational Performance Management Gestión del rendimiento de la organización OPP Organizational Process Performance / Rendimiento de Procesos de la organización OT Organizational Training/ Formación en la organización PI Product Integration / Integración del Producto PMC Project Monitoring and Control / Monitorización y control del Proyecto PP Project Planning / Planificación del Proyecto PPQA Process and Product Quality Assurance Aseguramiento de la calidad del Proceso y del Producto QPM Quantitative Project Management / Gestión cuantitativa del Proyecto RD Requirements Development Desarrollo de requisitos REQM Requirements Management / Gestión de requisitos RSKM Risk Management Gestión de riesgos 17 ACRÓNIMO SIGNIFICADO SAM Supplier Agreement Management / Gestión de acuerdos con Proveedores TS Technical Solution Solución técnica VAL Validation / Validación VER Verification / Verificación COTS Comercial Of The Shell / Comercial Fuera de la Plataforma API Interfaz de Aplicaciones WBS Work Breakdown Structure / Estructura de Descomposición del Trabajo CCB Configuration Control Board / Comité de Control de Configuración DoD Definition of Done / Definición de Terminado DoR Definition of Ready / Definición de Listo CRUD Create, Read, Update, Delete Crear, Leer, Actualizar, Eliminar XP Extreme Programming Programación Extrema CCC Card, Conversation and Confirmation ROI Return on ivestment Retorno de la inversión PB Prodcuct Backlog / Listado de producto US User Story / Historia de Usuario VSM Visual Story Mapping / Mapeo visual de historias ES Epic Story / Historia Épica MVP Minimum Viable Product / Producto Mínimo Viable MMF Minimum Marketable Features / Características mínimas comercializables 18 ACRÓNIMO SIGNIFICADO TDD Test Driver Development / Desarrollo Guiado por Pruebas SB Sprint Bakclog / Pila del Sprint IP Inception Phase / Fase Inicial SP Sprint Planning / Planeación del Sprint SR Sprint Review / revisión del sprint SRv Sprint Retrospective / Retrospectiva del Sprint PP Pair Programing Programación en parejas SE Sprint Execution / Ejecución del Sprint TR Test Result / Resultado de Pruebas CMMI - Dev Capability Maturity Model® Integration development Modelo de capacidad de Madurez Integrado para el Desarrollo 19 CAPÍTULO I: INTRODUCCIÓN El modelo CMMI y el framework SCRUM son guías para el desarrollo de software de alta calidad, diferentes empresas han tratado de implementar por separado dichas guías encontrando diversas dificultades y desafíos para lograrlo, en muchos casos no alcanzaron su objetivo, ante las dificultades que las empresas encuentran para la implementación por separado, esto los ha llevado a considerar que es imposible que las guías puedan coexistir. En el presente trabajo se creará un manual para combinar el nivel de capacidad 2 de CMMI con SCRUM, siendo la estructura del documento la siguiente: Capítulo I, se explica los objetivos generales y específicos, justificando la investigación y estableciendo los alcances, las limitaciones y se explica la metodología de investigación, el tipo de investigación, el criterio de clasificación, las unidades de análisis, variables, técnica e instrumentos, procedimientos y análisis, dando una reseña sobre cada uno de los temas que conforman este capítulo, además se elabora el manual de nivel de capacidad 2 de CMMI con SCRUM. Capítulo II, se definen los objetivos que se pretenden lograr con la investigación apoyándose de documentación existente, de igual forma se define la justificación, alcances del estudio y sus limitaciones. Capítulo III, se aborda el estado del arte, exponiendo los niveles de capacidad de CMMI y las prácticas de SCRUM que son convergentes. Capítulo IV, este capítulo contendrá las recomendaciones hechas por las entidades que revisarán el manual, dando un punto de vista respecto a la dificultad que tendría una organización al tratar de implementarlo. Capítulo V, se exponen las conclusiones del trabajo. 1.1 DESCRIPCIÓN DEL PROBLEMA En la actualidad el sector gobierno y el privado, se encuentran en la búsqueda de estrategias que les permitan alcanzar sus objetivos de una forma rápida y eficiente; al tener ambos sectores áreas de desarrollo de software, consideran estratégico que dichas áreas contribuyan al logro de mismos, por ello bajo este enfoque aplican técnicas, métodos o metodologías ágiles que ayudan a ejecutar actividades de desarrollo de programas informáticos mucho más eficientes los cuales presentan pros y contras. Por ejemplo, el utilizar modelos de desarrollo permite visualizar con mayor precisión todo lo que se necesita para construir un programa informático, la desventaja es que cuando el software finalice, probablemente los requerimientos iniciales habrán cambiado y el programa estará obsoleto. Para aliviar un poco este problema se puede aplicar los modelos de madurez y de capacidad integrados o CMMI, el cual ayuda hacer más eficiente la construcción de 20 programas, detectar fallos de manera temprana evitando de esta forma los tan temidos reprocesos, además segrega actividades y como su nombre lo indica agrega buenas prácticas que permiten mejorar los procesos de desarrollo de forma continua, sin mencionar la excelente documentación que se genera, facilitando futuros mantenimientos del software. Por otro lado, existen los marcos de trabajo ágiles, los cuales se caracterizan por construir un software en múltiples ciclos cortos, no necesitan contar con todos los requerimientos para brindar resultados rápidos, muy buenos cuando el cliente aún no sabe exactamente lo que quiere, gran parte de su éxito se apoya en la comunicación entre las partes que conforman los equipos de la construcción de software. La principal desventaja es la poca documentación formal que se genera durante sus ciclos de ejecución, dificultando mantenimientos futuros, sin embargo, esta última forma de trabajo es la más demandada por las empresas en los últimos años, debido a que esta genera un producto en el corto plazo. Al contraponer CMMI y SCRUM, se puede llegar a pensar que son contrarios debido a que por un lado, CMMI, requiere que se realice adecuadamente la documentación, pero dicha actividad se considera que resta dinamismo a los proyectos retrasando el desarrollo de los mismos, en cuanto a SCRUM, se considera un marco de trabajo que permite llevar poca o ninguna documentación, lo que genera que en algún momento se pierdan los motivos por los cuales evolucionó un requerimiento, creando un problema a futuro. A partir de lo anterior surge la interrogante para la empresa ¿Cuál marco de trabajo se debe utilizar?, esta respuesta debe estar orientada en la búsqueda de la eficiencia y la eficacia de los procesos, además debe permitir trazar la evolución de un proyecto. Existen varios marcos de trabajo ágiles entre los cuales se puede mencionar: programación extrema, Lean, Kanban, SCRUM, entre otros, de éstas la más aceptada es SCRUM, ya que es el marco de trabajo que mejor cumple los valores y principios del manifiesto ágil. CMMI es un modelo que ayuda a mejorar procesos, encuentra deficiencias y las optimiza, brinda lineamientos de trabajo, indica qué actividades deberían realizarse desde una perspectiva de gestión, hace énfasis en los controles y en la generación de documentos que apoyen sus mecanismos de trabajo, por otro lado, SCRUM, es un marco de trabajo que agiliza la construcción de un producto, segmentándolo en etapas, priorizando la entrega de un producto sobre cualquier contrato, control o documento, pues no considera a uno de éstos como un producto entregable funcional, lo definido en contratos pierde relevancia si el cliente lo amerita, la relación personal entre los integrantes del 21 proyecto es fundamental para el éxito de éste. Encontrar el punto medio de estas formas de trabajo aparentemente divergentes, para hacerlas coincidir y funcionar, ha sido una tarea compleja y que lleva mucho tiempo en la mente de varios autores, su análisis han sido plasmados en libros, artículos y conferencias: SCRUM and CMMI Level 5: The Magic Potion for Code Warriors (Sutherland, Jakobsen, & Johnson, Scrum and CMMI Level 5: The Magic Potion for Code Warriors, 2007), Speculation of CMMI in Agile Methodology (Aggarwal, Deep, & Singh, 2014), Integrating CMMI and Agile Development Case Studies and Proven Techniques for Faster Performance Improvement (McMahon, 2010), Implementing SCRUM (agile) and cmmi® together (Potter & Sakry, 2009). 1.2 PLANTEAMIENTO DEL PROBLEMA El área de desarrollo de software busca proveer un producto a corto plazo que sea de la mejor calidad posible cumpliendo con los requerimientos de los clientes; bajo este contexto se busca la implementación de CMMI o SCRUM. CMMI ayuda a mejorar la eficiencia de los modelos tradicionales de desarrollo de programas informáticos, pero estos están lejos de igualar la velocidad que posee una metodología ágil, en particular de SCRUM, pues ésta es considerada una de las mejores debido a que esta se salta procesos de control como, por ejemplo, estándares de algún tipo y documentación, lo que a futuro impacta el costo económico al incrementar el valor de desarrollo y mantenimiento. CMMI, por otro lado, tiene como finalidad mejorar los procesos y esto es posible ya que al igual que SCRUM, trabaja con procesos cíclicos, cada iteración tiene por objetivo ser mejor que la anterior, esto genera eficiencia de desarrollo, menos pérdida de tiempo en reprocesos. Por lo antes descrito, puede llegarse a concluir que CMMI y SCRUM, son dos formas de trabajo incompatibles, sin embargo, tienen muchas prácticas que coinciden en el mismo objetivo, como, por ejemplo, el proceso de recolección de requisitos, el proceso de codificación del programa informático y otras prácticas que la misma guía CMMI-Dev, menciona como comunes. En este trabajo proponemos construir un manual que combine las prácticas comunes de estas formas de trabajar, mejorando la eficiencia de uno y el control de los procesos de desarrollo del otro. Se ha diseñado una metodología específica para el presente trabajo, la cual consiste en tres fases, en la primer fase se realizará una recolección de diferentes documentos asignándoles un peso entre 1 y 10 donde 10 es el mayor puntaje y 1 es el menor, considerando solo aquellos documentos que obtengan una puntuación superior a 7; en la segunda fase se elegirán las prácticas 22 de SCRUM que convergen con las áreas de proceso de CMMI para la elaboración del manual, en la tercera fase se proveerá el manual construido en la fase 2 a la entidad, para que ésta realice observaciones sobre el mismo. 1.3 TIPO INVESTIGACIÓN Descriptiva (Hernández Sampieri, 2014). Debido a que se trata de identificar, clasificar y definir los procesos que se requieren para implementar CMMI con SCRUM 1.4 METODOLOGÍA 1.4.1 CRITERIO DE CLASIFICACIÓN ENFOQUE 1.4.2 MIXTO Cuantitativo. Debido a que se seleccionarán las áreas de procesos de CMMI que se ubiquen en el nivel de capacidad 2 y se acoplen a SCRUM. Cualitativo. Porque se recibirá una retroalimentación por parte de la persona entrevistada, quien brindará información de los procesos operativos que tienen y de los posibles ajustes que el manual requiere para que sea aplicado con mayor facilidad 1.4.3 CRITERIO DE CLASIFICACIÓN DE ALCANCE 1.4.3.1 DESCRIPTIVO Con los estudios descriptivos se busca especificar las propiedades, las características, los perfiles de personas, grupos, procesos, objetos o cualquier otro fenómeno que se someta a un análisis. Es decir, únicamente pretenden medir o recoger información de manera independiente o conjunta sobre los conceptos o las variables. 23 1.4.4 UNIDAD DE ANÁLISIS 1. Se desarrollará una investigación bibliográfica de las áreas de proceso de CMMI y las prácticas de SCRUM, con esta investigación se tendrán los insumos necesarios para realizar los respectivos análisis. 2. La convergencia existente entre el modelo CMMI y la metodología SCRUM ayudará a identificar las prácticas que pueden trabajar de forma conjunta. 3. La entidad es una unidad de análisis, pues brinda las recomendaciones que ayudarán a mejorar el manual de implementación CMMI a nivel de capacidad 2 con SCRUM. OBJETIVO ESPECÍFICO UNIDAD DE ANÁLISIS Identificar la documentación para el nivel 2 de capacidad de CMMI y SCRUM. Artículos, manuales y Libros Combinar las buenas prácticas de implementación del nivel de capacidad 2 de CMMI utilizando SCRUM. Convergencia entre CMMI y SCRUM Optimizar el manual de aplicación en base a observaciones y recomendaciones realizadas por la entidad. Entidad que utiliza el manual de implementación CMMI a nivel de capacidad 2 con SCRUM Tabla 1.4.1 Objetivos específicos y unidad de análisis. 1.4.5 VARIABLES UNIDAD DE ANÁLISIS VARIABLES Artículos, manuales y Libros Pertinencia Convergencia entre CMMI y SCRUM Pertinencia Entidad que utiliza el manual de implementación CMMI a nivel de capacidad 2 con SCRUM Recomendaciones Tabla 1.4.2 Unidad de análisis y variables. Los manuales y libros de CMMI y SCRUM a utilizar brindan las bases para formular el contenido y la estructura del manual. 24 1.4.5.1 VARIABLES Y SU MEDICIÓN 1. Pertinencia Establece si la documentación encontrada contiene lo requerido para realizar el manual, para ello se considerará el año de publicación y que aborde el nivel 2 de capacidad de CMMI y las buenas prácticas de SCRUM, así como también análisis de convergencia de CMMI con SCRUM. 2. Recomendaciones Son las apreciaciones que proporcionará el personal entrevistado después de leer el manual, con la finalidad de realizar mejoras sobre el mismo. 1.4.6 TÉCNICA E INSTRUMENTOS 1. Se utilizará la técnica de análisis de contenido, ya que se auxiliará de investigaciones previas y documentación que hace referencia al tema investigado, generando un banco de información que será analizado y clasificado para que posteriormente se describa cada clasificación. Los instrumentos que utilizará esta técnica son: a. Matriz de selección de documentación de CMMI, contiene la estructura de CMMI para el nivel de capacidad 2. Esta matriz se conforma de las siguientes columnas:  Categoría, indica la agrupación de los procesos.  Área, se colocará el área de proceso.  Nivel de capacidad, se colocará el nivel al que pertenece el área de proceso.  Herramientas, se colocarán las herramientas que se pueden utilizar para el área de proceso. b. Matriz de selección de documentación de SCRUM, contiene la estructura de SCRUM. Esta matriz se conforma de las siguientes columnas:  Etapa, indica la etapa en la que se encuentra el proceso de desarrollo dentro de SCRUM.  Sub-etapa, específica la acción que se está realizando dentro de la etapa. 25  Herramientas, indica cual herramienta se está utilizando en la respectiva sub-etapa. c. Matriz de convergencia de CMMI y SCRUM, esta matriz será la base para la construcción del manual, contiene todas las referencias bibliográficas en donde CMMI y SCRUM coinciden en sus prácticas. Esta matriz se conforma de las siguientes columnas:  CMMI, contiene la información de CMMI en nivel de capacidad 2. o Área de proceso, se colocarán las áreas de proceso de CMMI. o Herramienta, se colocarán las herramientas correspondientes al área de proceso.  SCRUM, contiene la información de SCRUM. o Sub-etapa, específica la acción que se está realizando dentro de la etapa. o Herramienta, indica la herramienta que se utiliza en la respectiva sub-etapa. d. Entrevista estructurada, será una entrevista dirigida a la entidad que implemente el manual, contará con una serie de preguntas específicas acerca de éste, con la intención de recibir una retroalimentación que ayude a mejorarlo. Para realizar la entrevista se han elaborado las siguientes preguntas:  ¿Qué dificultades encontró en la lectura del manual?  ¿Considera usted que el manual cubre sus procesos de negocio?  ¿Considera usted que el manual le ayudaría a mejorar sus procesos?  ¿Qué cambios le haría al manual para facilitar su aplicación? Las primeras tres preguntas tienen como finalidad obtener observaciones sobre el manual y con la última pregunta se busca obtener las recomendaciones. 2. La entrevista será la técnica que se utilizará para obtener una retroalimentación de todas aquellas observaciones que el manual pudiera generar. Los instrumentos que ésta empleará son: 26 a. Entrevista estructurada. Será una entrevista dirigida a la entidad que aplique el manual, tendrá un guión previamente definido, con el objetivo de recibir insumos que ayuden a mejorar el manual. VARIABLE TÉCNICA INSTRUMENTO Pertinencia Análisis de contenido  Matriz de selección de documentación de CMMI en nivel de capacidad 2.  Matriz de selección de documentación de SCRUM.  Matriz de convergencia de CMMI y SCRUM Recomendaciones Entrevista Entrevista estructurada Tabla 1.4.3 Variable, técnica e instrumento. 1.4.7 PROCEDIMIENTOS Y ANÁLISIS La presente investigación busca la creación de un manual que combine el marco de trabajo CMMI en nivel de capacidad 2 y SCRUM, para ello se han definido 3 fases. 1. En la fase uno, se identificará la documentación para el nivel de capacidad 2 de CMMI y la documentación de SCRUM, para ello se elaborará dos matrices una para CMMI y otra para SCRUM en las que se identificarán los componentes clave para realizar la investigación. 2. En la fase dos, se combinarán las buenas prácticas de implementación de nivel de capacidad 2 de CMMI con SCRUM, para ello se elaborará una matriz de convergencia donde se colocarán las áreas de proceso del nivel de capacidad 2 de CMMI y sus herramientas con su respectiva correspondencia con las fases y herramientas de SCRUM; además será en esta fase donde se creará él manual. 3. En la fase tres, se mejorará el manual en base a observaciones y recomendaciones realizadas por una empresa pública y una privada, para ello se proporcionará dicho manual a los responsables de las áreas de desarrollo y posteriormente se les realizará una entrevista con el objetivo de obtener observaciones y recomendaciones que ayuden a mejorar la redacción y comprensión del manual. 1.4.7.1 INSTRUMENTOS A UTILIZAR POR OBJETIVO 1. Identificar la documentación para el nivel 2 de capacidad de CMMI y SCRUM. 27  Matriz de selección de documentación de CMMI, en esta matriz se colocará la estructura de CMMI la cual está conformado a nivel macro por categoría de proceso, áreas de procesos, nivel de capacidad y las herramientas que utiliza, todo delimitado al nivel de capacidad 2.  Matriz de selección de documentación de SCRUM, en esta matriz se colocará la información pertinente a SCRUM, identificando etapas, sub-etapas y las herramientas que se emplean en cada sub-etapa. 2. Combinar las buenas prácticas de implementación del nivel de capacidad 2 de CMMI utilizando SCRUM.  Matriz de convergencia, en esta matriz se colocarán las áreas de procesos de CMMI con sus respectivas herramientas colocando como contraparte las fases y herramientas de SCRUM, las cuales sean convergentes entre sí; para establecer dicha correspondencia se realizará una comparación entre la descripción de la práctica de CMMI contra la descripción de la práctica de SCRUM y aquellas descripciones que sean coincidentes se considerarán convergentes. 3. Optimizar el manual de aplicación en base a observaciones y recomendaciones realizadas por la entidad.  Entrevista, para mejorar el manual se proporcionará a los responsables de desarrollo de las empresas públicas y privadas un manual para que lo lean y al final se realizará una entrevista, la cual busca obtener observaciones y recomendaciones para le mejora de la redacción del manual. 28 29 CAPÍTULO II: ANTECEDENTES El que la guía CMMI-Dev brinde la pauta para que el modelo y la metodología funcionen juntos, es porque CMMI como tal, no define cómo hacer. Así, se abre la posibilidad que puedan implementarse diferentes estrategias para lograr el objetivo definido por CMMI. En la actualidad existe mucha información documentada en artículos y conferencias, en donde expresan los beneficios obtenidos, así como el costo que se debe de pagar. El homologar CMMI y las metodologías ágiles, en el caso del presente documento SCRUM, lleva aproximadamente un poco más de una década de estudio y el enfoque que han tenido estos estudios está orientado a generar prácticas de equivalencias entre estos, en otros términos, el objetivo de los estudios es implementar CMMI utilizando metodologías ágiles para alcanzar las prácticas generales de CMMI. 2.1 OBJETIVOS 2.1.1 GENERALES 1. Crear un manual que ayude a implementar el nivel de capacidad 2 de CMMI con SCRUM en el área de desarrollo de software. 2.1.2 ESPECÍFICOS 1. Identificar la documentación para el nivel 2 de capacidad de CMMI y SCRUM. 2. Combinar las buenas prácticas de implementación del nivel de capacidad 2 de CMMI utilizando SCRUM. 3. Optimizar el manual de aplicación en base a observaciones y recomendaciones realizadas por la entidad. 2.2 JUSTIFICACIÓN Las áreas de desarrollo de software de las diferentes empresas buscan la eficiencia y la eficacia en los procesos internos, es en esta búsqueda que encuentran marcos de trabajo como CMMI y metodologías de desarrollo como lo es SCRUM. En su afán de aplicar alguna de las metodologías o ambas se enfrentan a nuevos retos de los cuales en muchas ocasiones no los pueden superar, realizando implementaciones deficientes o inclusive abandonando las implementaciones al poco tiempo de iniciarlas, por ello se ha planteado la creación de un manual que oriente a las áreas de desarrollo de software en su implementación del nivel de capacidad 2 y el nivel de CMMI junto con SCRUM. 30 2.3 ALCANCES Y LÍMITES 2.3.1 ALCANCES El presente estudio tiene como alcance elaborar un manual para la aplicación del nivel de capacidad 2 de CMMI combinado con SCRUM. Además, se plasmará la forma en que se construyó el manual exponiendo las partes donde se combinan CMMI y SCRUM. Con la presente investigación no se intenta demostrar la efectividad que tiene dicho manual al aplicarse en las áreas de desarrollo de software de las empresas. 2.3.2 LIMITACIONES El manual será desarrollado con la versión 1.3 CMMI-Dev dicha versión fue lanzada en el mes de noviembre del año 2010, actualmente se encuentra la versión 2. Se utilizarán manuales de SCRUM disponibles después del año 2000. El manual será entregado a 2 empresas 1 privada y 1 pública para que emitan sus observaciones y recomendaciones. 31 CAPÍTULO III: ESTADO DEL ARTE Incrementar la eficiencia en los procesos de desarrollo de software y obtener una mejor calidad en los productos generados es el objetivo de las empresas, para lograrlo muchas empresas implementan metodologías ágiles, experimentando una baja en la productividad durante las primeras iteraciones “La transición al nuevo proceso SCRUM redujo temporalmente la productividad del equipo. Sin embargo, los equipos se habían recuperado y mejorado la productividad al final de la cuarta iteración” (Williams, Brown, Meltzer, & Nagappan, 2011), presentando retos para su implementación tales como “falta de experiencia, la cultura organizacional y la falta de comunicación.” (Hanslo, Mnkandla, & Vahed, 2019). En la Figura 3.1, se muestra los factores que afecta la adopción de SCRUM. Figura 2.3.1 Factores que afecta la adopción de SCRUM (Hanslo, Mnkandla, & Vahed, 2019) Además de mejorar sus procesos las empresas buscan la forma de medir que tanto los procesos han mejorado, es en este punto donde empiezan a considerar el modelo de capacidad de madurez integrado para el desarrollo (Capability Maturity Model® Integration dev., CMMI dev), el cual es un compendio de “buenas prácticas para el desarrollo de productos y servicios” (Carnegie Mellon University, 2010), encontrando acá un punto de convergencia, por un lado se posee SCRUM que “ofrece una forma personalizada de trabajar en diferentes proyectos que tienen una variedad de 32 requisitos y que tienen ventajas como la selección flexible de requisitos para sprints y ningún procedimiento específico a seguir” (Srivastava, Bhardwaj, & Saraswat, 2017). A partir de lo anterior surge la pregunta ¿Podrá SCRUM aceptar las mejores prácticas planteadas en CMMI-dev?, existen estudios que dicen “CMMI y el método ágil SCRUM son compatibles. A nivel de proyecto, CMMI se enfoca en un alto nivel de abstracción en lo que hacen los proyectos, no en qué metodología de desarrollo se usa, mientras que SCRUM se enfoca en cómo los proyectos desarrollan productos. Por lo tanto, CMMI y SCRUM pueden coexistir. Se puede obtener mucho valor de las sinergias de SCRUM y CMMI” (Lina & Dan, 2012). En la figura 2.3.2 se plantea que al implementar los niveles de madurez el riesgo en el desarrollo de aplicaciones disminuye. Figura 2.3.2 Los cinco niveles del modelo de madurez de capacidades (Lina & Dan, 2012). Para realizar la convergencia entre estos mundos algunos investigadores tomaron como base las áreas de proceso, “Para cada área de proceso, se realizó un mapeo entre sus prácticas específicas y las prácticas SCRUM. Se identificaron varias consideraciones para establecer este mapeo, identificando lagunas y fortalezas” (C. Marcal, Furtado Soares, & Belchior, 2007), otros investigadores cuyo “enfoque es utilizar CMMI para ayudar a una organización a institucionalizar los métodos ágiles” (Sutherland, Jakobsen, & Johnson, Scrum and CMMI Level 5: The Magic Potion for Code Warriors, 2007), considerando como las prácticas genéricas ayudarán a 33 institucionalizar una metodología ágil. Otros investigadores realizarón su estudio combinando CMMI, SCRUM, XP y Kanban a nivel de práctica específica (Bougroun & Adil Zeaaraoui, 2014). En el presente trabajo tiene un enfoque mediante el cual se ha identificado los diferentes productos que solicita CMMI para sus diferentes prácticas específicas indicando con que artefacto de SCRUM puede obtenerse, de esta forma una empresa que ya trabaje con SCRUM o desee trabajar con SCRUM, pueda encontrar un aliado en CMMI para la mejora de sus procesos y descubra que CMMI no es antagónico a SCRUM, sino más bien, es un catalizador que le facilitará mejorar sus procesos para garantizar la calidad de sus productos y realizar predicciones lo más apegada a la realidad sobre los tiempos de desarrollo. 34 3.1 CMMI CMMI es un marco de trabajo que permite evolucionar los procesos de cualquier empresa, para lograrlo se requiere la comprensión de Niveles de Madurez y Niveles de Capacidad. CMMI posee una estructura definida que se asemeja a una estructura de árbol, siendo los niveles desde el superior al inferior: Categorías de Procesos, Áreas de Proceso, Metas Genéricas y Metas Específicas, Prácticas Genéricas y Prácticas Específicas. Una categoría de procesos agrupa a diferentes áreas de proceso, el área de proceso es “Un grupo de prácticas relacionadas”, las metas genéricas son “metas que son comunes a diferentes áreas de proceso” y las metas específicas son “metas particulares para el área de proceso”, las metas poseen prácticas las que pueden ser genéricas y específicas, una práctica genérica es una actividad común a diferentes áreas de proceso y una práctica específica son las actividades propias de un área de proceso. CMMI es un marco de trabajo que permite evolucionar los diferentes procesos de una organización, para ello se busca alcanzar diferentes metas genéricas y específicas, mediante la aplicación de sus prácticas genéricas y específicas. Nivel Representación continua Niveles de capacidad Representación por etapas Niveles de madurez Nivel 0 Incompleto Nivel 1 Realizado Inicial Nivel 2 Gestionado Gestionado Nivel 3 Definido Definido Nivel 4 Gestionado cuantitativamente Nivel 5 En optimización Tabla 3.1.1 Niveles de CMMI. (Carnegie Mellon University, 2010) La evolución de las áreas de proceso se puede lograr a través de niveles, los cuales pueden ser de madurez o de capacidad, y que son aproximaciones para la mejora de procesos y reciben el nombre de “representaciones”, cuando se refiere a nivel de madurez, se considera que es una representación por etapas y al referirse al nivel de capacidad, se considera que es una representación continua. Dichas representaciones no están en competencia debido a que son caminos diferentes para alcanzar un mismo fin. La representación por etapas o lograr un nivel de madurez se vuelve complejo de alcanzar debido a que busca que todas las áreas de proceso de una 35 categoría evolucionen al mismo ritmo, en cambio la representación continua o lograr niveles de capacidad, permite que una única área de proceso evolucione. La mejora de procesos se logra a través de dos representaciones la continua y por etapas, ambas representaciones poseen niveles; la representación continua posee niveles de capacidad y la representación por etapas posee niveles de madurez; la representación continua posee 4 niveles de capacidad y la representación por etapas posee 5 niveles de madurez. La tabla 3.1.1, nos permite apreciar los niveles de capacidad y los niveles de madurez, se puede observar que los niveles de capacidad se identifican con los números del 0 al 3 y los niveles de madurez se identifican con los números del 1 al 5, ambas representaciones poseen el nivel “gestionado” y el nivel “definido”. Los niveles de la representación continua son 0 Incompleto, 1 Realizado, 2 Gestionado, 3 Definido; un área de proceso llega a un nivel de capacidad cuando cumple las metas genéricas de dicho nivel. Proceso Realizado: es el atributo que se les da a las áreas de proceso que aplican sus actividades específicas y alcanzan sus metas específicas. Proceso Gestionado: es el atributo que reciben las áreas de proceso al lograr el nivel de capacidad realizado y además “está planificado y ejecutado de acuerdo a una política, emplea personas cualificadas que tienen los recursos adecuados para producir salidas controladas, involucra a las partes interesadas relevantes, es monitorizado, controlado y revisado, y se evalúa para determinar la adherencia a la descripción del proceso” (Carnegie Mellon University, 2010). En este nivel el proceso está institucionalizado y existen objetivos definidos, por ejemplo, costos y calendarización; elementos de la empresa tales como proyectos, equipo de trabajo o una función organizativa, puede ejecutar el proceso. Un proceso en el nivel gestionado posee los controles necesarios que garantizan su ejecución durante los momentos de presión. La organización ha asimilado el proceso, tiene definido metas, el alcance, productos esperados en puntos específicos de la vida del proyecto, se cuenta con un equipo de trabajo cohesionado capaz de realizar acuerdos y en caso de evolucionar los requerimientos se modifican los acuerdos según sea necesario. El nivel gestionado y realizado se diferencian principalmente por el grado de gestión que puede alcanzar un proceso, esto significa que el proceso gestionado debe ser planificado, y dicha planificación puede ser componente de una planificación mayor permitiendo controlar la ejecución 36 del proceso y realizar los ajustes necesarios cuando los resultados no son los esperados; el proceso gestionado forma parte de la organización y se ejecuta cada vez que sea requerido según los criterios definidos. “Los niveles 2 y 3 ayudan a la organización a estar preparadas para la medición en los niveles superiores, monitoreando adecuadamente las métricas” (Lopes Margarido, Moreira Vidal, & Vieira, 2012). CMMI provee una serie de áreas de proceso clasificadas en categorías las cuales evolucionan alcanzando un nivel de madurez o de capacidad según la planificación de la empresa. Las áreas de proceso que provee CMMI se describen en la tabla 3.1.2 estructura de área de procesos, la cual contiene la categoría, Área de proceso, abreviatura (abr.), Nivel de Madurez (N.M.) y los niveles de capacidad del 1 al 3 (N.C. 1, N.C. 2, N.C. 3). 37 Categoría Área de proceso Abr. N.M. N.C. 1 N.C. 2 N.C. 3 Soporte Gestión de Configuración CM 2 Perfil Objetivo 2 Soporte Medición y Análisis MA 2 Gestión de proyecto Monitorización y Control del Proyecto PMC 2 Gestión de proyecto Planificación del Proyecto PP 2 Soporte Aseguramiento de la Calidad del Proceso y del Producto PPQA 2 Gestión de proyecto Gestión de Requisitos REQM 2 Gestión de proyecto Gestión de Acuerdos con Proveedores SAM 2 Soporte Análisis de Decisiones y Resolución DAR 3 Perfil Objetivo 3 Gestión de proyecto Gestión Integrada del Proyecto IPM 3 Gestión de procesos Definición de Procesos de la Organización OPD 3 Gestión de procesos Enfoque en Procesos de la Organización OPF 3 Gestión de procesos Formación en la Organización OT 3 Ingeniería Integración del Producto PI 3 Ingeniería Desarrollo de Requisitos RD 3 Gestión de procesos Gestión de Riesgos RSKM 3 Ingeniería Solución Técnica TS 3 Ingeniería Validación VAL 3 Ingeniería Verificación VER 3 Gestión de procesos Rendimiento de Procesos de la Organización OPP 4 Perfil Objetivo 4 Gestión de proyecto Gestión Cuantitativa del Proyecto QPM 4 Soporte Análisis Causal y Resolución CAR 5 Perfil Objetivo 5 Gestión de procesos Gestión del Rendimiento de la Organización OPM 5 Tabla 3.1.2 Estructura de Áreas de proceso. (Carnegie Mellon University, 2010) 38 En el presente trabajo se abordará desde la capacidad 0 hasta la capacidad 2, haciendo las siguientes consideraciones:  En capacidad cero o incompleto, no existe un conocimiento sobre la forma de gestionar los requisitos, a pesar de contar con algunas actividades para su gestión, éstas resultan de la necesidad y no se ha dado por aceptado por todas las partes que debe realizarse de dicha forma, podrían emplearse herramientas que no son las más adecuadas evitando que el proceso sea eficiente. Muchas empresas que se encuentran en la situación antes descrita realizan los proyectos, pero no poseen una guía de planificación y ejecución aceptada por todas las partes interesadas, si bien producen resultados, no pueden predecir la duración del proyecto o el grado de avance en un momento dado, proveyendo una estimación errónea de tiempo y costo del mismo.  En capacidad 1 o realizado, la empresa ha logrado que un área de proceso alcance sus metas específicas mediante la ejecución de sus prácticas específicas, en este nivel de capacidad, la empresa debe tener un conocimiento claro de las metas y prácticas específicas de las áreas de proceso a implementar.  En capacidad 2 o gestionado, la empresa ha asumido como propia las diferentes metas y prácticas específicas de los procesos asignando los recursos y personal necesario para ejecutarlas, contando con una documentación adecuada sobre la planificación y ejecución de las diferentes actividades de las áreas de proceso, monitorizando, controlando y revisando la ejecución de las actividades y sus resultados; además se garantiza que se cumplan las etapas descritas en la definición del proceso. Al ser el nivel de capacidad 2 un nivel que involucra de forma directa a la empresa, no se podrá abordar en el manual, debido a que cada empresa tiene una cultura propia y cuenta con diferentes tiempos de asimilación, en este punto la alta gerencia tiene una conciencia de las ventajas de aplicar CMMI y apoya su implementación. Las apreciaciones anteriores aplican a todas las áreas de proceso que se abordarán en el presente documento. 39 3.1.1 ÁREAS DE PROCESO PARA LA ELABORACIÓN DEL MANUAL En esta sección expone un resumen de cada una de las áreas de proceso a abordar para la elaboración del manual, las áreas de proceso se han seleccionado tomando como base el ciclo de vida de desarrollo de software y la gestión de proyectos, con la finalidad de tener una visión amplia sobre el manejo de proyectos de software. 3.1.1.1 GESTIÓN DE REQUISITOS (REQM) “El propósito de la Gestión de Requisitos (REQM) es gestionar los requisitos de los productos y los componentes de producto del proyecto, y asegurar la alineación entre esos requisitos, y los planes y los productos de trabajo del proyecto” (Carnegie Mellon University, 2010). Para la creación de un producto es indispensable identificar los diferentes requisitos a cumplir para su elaboración, los cuales deben quedar plasmados y ser comprendidos por cada una de los diferentes involucrados para su elaboración. El área de proceso Gestión de requisitos, permite tener un control sobre los diferentes requisitos generados por un proyecto ya sean éstos de tipo técnicos o no. Existe un área, el área de proceso Desarrollo de Requisitos la cual genera requisitos de producto y de componente de producto, dichos requisitos se administran en el área de proceso gestión de requisitos. El área de gestión de requisitos administra los diferentes cambios que éstos sufren, llevando un registro documental del cambio y los motivos que lo produjeron permitiendo establecer una trazabilidad bidireccional de los requisitos origen. 3.1.1.1.1 META ESPECÍFICA 1: GESTIONAR LOS REQUISITOS “Los requisitos se gestionan y las inconsistencias con los planes y productos de trabajo del proyecto se identifican” (Carnegie Mellon University, 2010). Lo anterior indica que para gestionar los requisitos se ejecutan una serie de acciones que permiten identificarles, controlarlos y monitorizarlos además de identificar y controlar los ajustes requeridos en cualquier punto en el tiempo con la finalidad de alcanzar el objetivo del proyecto. 3.1.1.1.2 PRÁCTICA ESPECÍFICA 1.1: COMPRENDER LOS REQUISITOS “Desarrollar una comprensión del significado de los requisitos con los proveedores de los requisitos” (Carnegie Mellon University, 2010). Toda empresa que ejecuta diferentes proyectos genera diversidad de requisitos, los cuales deben estar acordes a las necesidades del proyecto, dichos requerimientos deben ser comprendidos a cabalidad por todos los miembros del equipo, con la creación de canales de comunicación que filtren dichos requerimientos se logra tener certeza sobre lo solicitado al realizar un análisis sobre la necesidad y lo esperado de lo solicitado. 40 Productos esperados. Al realizar la práctica específica se espera como resultado algunas herramientas como las siguientes: 1. Listas de criterios para distinguir a los proveedores apropiados de requisitos. 2. Tipificación de los requisitos. 3. Criterios para la evaluación y la aceptación de los requisitos. 4. Resultados del análisis frente a los criterios. 5. Un conjunto de requisitos aprobados. Sub Prácticas. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Establecer criterios para distinguir a los proveedores apropiados de requisitos. 2. Establecer criterios objetivos para la evaluación y aceptación de los requisitos. Al no contar con criterios para la evaluación adecuada de requisitos genera que éstos sean rechazados por el cliente o que sea reprocesados, generando pérdida de recursos. Se listan algunos criterios para evaluación:  Clara y correctamente establecidos.  Completos.  Consistentes unos con otros.  Identificados de forma única.  Consistentes con el enfoque de la arquitectura y con las prioridades de los atributos de calidad.  Apropiados para implementar.  Verificables (es decir, que se pueden probar).  Trazables.  Alcanzables.  Vinculados al valor de negocio.  Identificados como una prioridad para el cliente. 3. Analizar los requisitos para asegurar que se cumplen los criterios establecidos. 4. Alcanzar una comprensión de los requisitos con los proveedores de requisitos para que los participantes del proyecto puedan comprometerse con ellos. 41 3.1.1.1.3 PRÁCTICA ESPECÍFICA 1.2: OBTENER EL COMPROMISO SOBRE LOS REQUISITOS. El equipo involucrado debe estar comprometido con los requisitos aprobados en su momento y tomar en cuenta que estos pueden evolucionar y dicha evolución afectará los planes, actividades y productos de trabajo del proyecto. Algunos productos de trabajo que se producirán son: 1. Evaluaciones del impacto de los requisitos. 2. Compromisos documentados de los requisitos y de sus cambios. Sub-Prácticas. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Evaluar el impacto de los requisitos sobre los compromisos existentes. Todo requisito tiene un impacto directo sobre los diferentes actores del proyecto, es por ello por lo que al identificar un nuevo requisito o cuando éste experimente algún cambio se evalúe el impacto que tendrá en los diferentes actores. 2. Negociar y registrar los compromisos. La evolución de los compromisos es un proceso natural en todo proyecto, dicha evolución debe ser controlada mediante la negociación y aceptación de dichos cambios antes de adquirir un nuevo compromiso ante un requisito o cambio de requisito. 3.1.1.1.4 PRÁCTICA ESPECÍFICA 1.3: GESTIONAR LOS CAMBIOS A LOS REQUISITOS. Durante el desarrollo de los proyectos, algunos de sus requisitos pueden cambiar debido a la evolución que tienen las necesidades, dichos cambios deben gestionarse de una forma eficiente y eficaz, por ello para evaluarlos adecuadamente debe conocerse el origen de cada requisito y que exista documentación sobre el análisis de dicho cambio. Algunos productos de trabajo que se producirán son: 1. Petición de cambio de requisitos. 2. Informes de impacto del cambio de requisitos. 3. Estado de los requisitos. 4. Base de datos de requisitos. Sub prácticas. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Documentar todos los requisitos y los cambios a los requisitos que se reciben o generan por el proyecto. 42 2. Mantener una historia de cambios de los requisitos, incluyendo el análisis razonado de los cambios. Contar con un registro de la evolución de los registros permite trazar sus cambios en el tiempo. 3. Evaluar el impacto de los cambios de requisitos desde el punto de vista de las partes interesadas relevantes. Un cambio de un requisito puede ser tan superficial que no afecta el proyecto o tan estructural que puede generar cambios dramáticos para la ejecución del proyecto afectando a todos los involucrados. 4. Poner a disposición del proyecto los requisitos y los datos de los cambios. 3.1.1.1.5 PRÁCTICA ESPECÍFICA 1.4: MANTENER LA TRAZABILIDAD BIDIRECCIONAL DE LOS REQUISITOS. Existen requisitos de alto nivel que generan requisitos de bajo nivel, debe existir una relación vinculante entre el requisito de alto nivel que origina los requisitos de bajo nivel y viceversa, de esta forma se puede identificar si todos los requisitos de alto nivel se han tratado y si los requisitos de bajo nivel pueden vincularse hacia una fuente válida. La vinculación de requisitos también se da hacia productos de trabajo intermedios y finales, modificación en la documentación de diseño y planes de pruebas. Dicha vinculación puede presentarse en toda dirección y es utilizada para valorar el impacto que tiene un cambio de requisitos sobre el proyecto. Con la finalidad de mantener que tanto están vinculados puede hacerse uso de diferentes herramientas como lo son hojas electrónicas, sistemas de gestión de requisitos entre otros. Algunos productos de trabajo que se producirán son: 1. Matriz de trazabilidad de los requisitos. 2. Sistema de seguimiento de los requisitos. Sub prácticas. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Mantener la trazabilidad de los requisitos para asegurar que la fuente de los requisitos de nivel más bajo (es decir, inferidos) está documentada. 2. Mantener la trazabilidad de los requisitos desde un requisito a sus requisitos inferidos y a la asignación a los productos de trabajo. 43 Los productos de trabajo para los cuales la trazabilidad se puede mantener incluyen la arquitectura, los componentes de producto, las iteraciones de desarrollo (o incrementos), las funciones, las interfaces, los objetos, las personas, los procesos y otros productos de trabajo. 3. Generar una matriz de trazabilidad de requisitos. 3.1.1.1.6 PRÁCTICA ESPECÍFICA 1.5: ASEGURAR EL ALINEAMIENTO ENTRE EL TRABAJO DEL PROYECTO Y LOS REQUISITOS. Todo esfuerzo que se realice para la ejecución del proyecto y la obtención de los productos, deben estar en concordancia con los requisitos. Algunos productos de trabajo que se producirán son: 1. Documentación de inconsistencias entre los requisitos y los planes del proyecto y los productos de trabajo, incluyendo fuentes y condiciones. 2. Acciones correctivas. Sub prácticas. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Revisar los planes del proyecto, las actividades y los productos de trabajo en cuanto a la consistencia con los requisitos y los cambios realizados sobre ellos. 2. Identificar la fuente de la inconsistencia (si existe). 3. Identificar cualquier cambio que se debería realizar a los planes y a los productos de trabajo resultantes de los cambios a la línea base de requisitos. 4. Iniciar cualquier acción correctiva necesaria. 3.1.1.2 GESTIÓN DE RIESGOS (RSKM) “El propósito de la Gestión de Riesgos (RSKM) es identificar problemas potenciales antes de que ocurran, para que las actividades de tratamiento de riesgos puedan planificarse e invocarse según sea necesario a lo largo de la vida del producto o del proyecto para mitigar los impactos adversos sobre la consecución de objetivos." (Carnegie Mellon University, 2010). La ejecución de un proyecto sin problemas es algo imposible, existen factores que de una u otra forma afecta la ejecución de éste, para reducir el impacto de algún incidente deben establecerse mecanismos de supervisión encaminados a la identificación temprana de posibles riesgos, que garanticen la comunicación de éstos a las partes responsables de la toma de decisiones. 44 3.1.1.2.1 META ESPECÍFICA 1: PREPARAR LA GESTIÓN DE RIESGOS “La preparación de la gestión de riesgos se lleva a cabo” (Carnegie Mellon University, 2010). Estar preparados para afrontar un incidente es la diferencia entre el éxito o el fracaso de un proyecto, para ello debe establecerse en el plan una estrategia que permitan crear alertas tempranas a partir de la información recabada. 3.1.1.2.2 PRÁCTICA ESPECÍFICA 1.1: DETERMINAR LAS FUENTES Y LAS CATEGORÍAS DE RIESGOS “Determinar las fuentes y las categorías de los riesgos” (Carnegie Mellon University, 2010). Conocer que provoca una determinada situación permite realizar acciones para corregirlas o evitarlas, por ello es importante identificar el origen de un riesgo. Algunos productos de trabajo que se producirán son: 1. Listas de fuentes de riesgos (externas e internas). 2. Lista de categorías de riesgos. Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Determinar las fuentes de riesgos. 2. Determinar las categorías de riesgos. 3.1.1.2.3 PRÁCTICA ESPECÍFICA 1.2: DEFINIR LOS PARÁMETROS DE RIESGOS “Definir los parámetros usados para analizar y clasificar los riesgos y para controlar el esfuerzo de la gestión de riesgos” (Carnegie Mellon University, 2010). Medir un riesgo facilita la toma de decisiones para su mitigación para ello deben establecerse parámetros que permitan priorizarlos. Algunos productos de trabajo que se producirán son: 1. Criterios de evaluación, clasificación, y priorización de riesgos. 2. Requisitos de la gestión de riesgos (p. ej., niveles de control y de aprobación, intervalos de reevaluación). Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Definir criterios consistentes para evaluar y cuantificar la probabilidad del riesgo y los niveles de gravedad. 2. Definir los umbrales para cada categoría de riesgo. 45 3. Definir los límites de la extensión a la cual se aplican los umbrales frente a una categoría o dentro de ella. 3.1.1.2.4 PRÁCTICA ESPECÍFICA 1.3: ESTABLECER UNA ESTRATEGIA DE GESTIÓN DE RIESGOS “Establecer y mantener la estrategia que se usará para la gestión de riesgos” (Carnegie Mellon University, 2010). La gestión de riesgos es un trabajo colaborativo, e impacta a todo el personal dentro del proyecto, por ello debe crearse una estrategia al inicio del proyecto donde todos los involucrados aporten información para identificar los riesgos. Algunos productos de trabajo que se producirán son: 1. Estrategia de gestión de riesgos del proyecto. 3.1.1.2.5 META ESPECÍFICA 2: IDENTIFICAR Y ANALIZAR LOS RIESGOS “Los riesgos se identifican y analizan para determinar su importancia relativa” (Carnegie Mellon University, 2010). La obtención de la mayor información posible para identificar los riesgos es importante, pero además debe realizarse un análisis minucioso sobre dicha información para clasificar e identificar adecuadamente los riesgos estableciéndolos en categorías previamente definidas. 3.1.1.2.6 PRÁCTICA ESPECÍFICA 2.1: IDENTIFICAR LOS RIESGOS “Identificar y documentar los riesgos” (Carnegie Mellon University, 2010). Realizar un análisis exhaustivo que permita identificar las vulnerabilidades o debilidades en un proyecto, permitirá crear medidas que permitan mitigarlas, para ello debe realizarse una documentación oportuna. Algunos productos de trabajo que se producirán son: 1. Lista de riesgos identificados, incluyendo el contexto, las condiciones y las consecuencias de la ocurrencia del riesgo. Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Identificar los riesgos asociados con el coste, el calendario y el rendimiento. 2. Revisar los elementos del entorno que pueden afectar al proyecto. 3. Revisar todos los elementos de la estructura de descomposición del trabajo como parte de la identificación de riesgos para ayudar a asegurar que se consideran todos los aspectos del esfuerzo del trabajo. 46 3.1.1.2.7 PRÁCTICA ESPECÍFICA 2.2: EVALUAR, CLASIFICAR Y PRIORIZAR LOS RIESGOS “Evaluar y clasificar cada riesgo identificado usando las categorías y los parámetros definidos para el riesgo, y determinar su prioridad relativa” (Carnegie Mellon University, 2010). Asignarles una prioridad a los riesgos identificados para ser atendidos de acuerdo con dicha prioridad y crear una relación de dependencia entre riesgos de menor a mayor prioridad permite garantizar que los riesgos de menor prioridad no sean desatendidos. Algunos productos de trabajo que se producirán son: 1. Lista de riesgos y su prioridad asignada. Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Evaluar los riesgos identificados usando parámetros definidos del riesgo. 2. Clasificar y agrupar los riesgos de acuerdo con las categorías de riesgo definidas. 3. Priorizar los riesgos para la mitigación. 3.1.1.2.8 META ESPECÍFICA 3: MITIGAR LOS RIESGOS. “Los riesgos son tratados y mitigados de manera apropiada para reducir los impactos adversos sobre la obtención de los objetivos” (Carnegie Mellon University, 2010). Una vez identificados los riesgos, debe procederse a crear planes de mitigación para que en caso de ocurrir se reduzca su impacto; además se deben crear planes de contingencia en dado caso no funcione adecuadamente el plan de mitigación. 3.1.1.2.9 PRÁCTICA ESPECÍFICA 3.1: DESARROLLAR LOS PLANES DE MITIGACIÓN DE RIESGOS “Desarrollar un plan de mitigación de riesgos en concordancia con la estrategia de gestión de riesgos” (Carnegie Mellon University, 2010). Crear los planes de acción para reducir o eliminar el impacto de los riesgos permite que la ejecución de un proyecto no tenga mayores contratiempos, las acciones a plasmar dentro del plan para abordar a un riesgo crítico deben categorizarse como alternativas, temporales y recomendada, además, debe crearse planes de contingencia que permitan actuar en dado caso el riesgo se materialice, los riesgos a incluir en los planes pueden ser solo los críticos o aquellos cuya consecuencia afecte en gran medida al proyecto; todos los riesgos deben ser monitorizados para poder tomar acciones oportunas en caso que se den. Algunos productos de trabajo que se producirán son: 1. Opciones documentadas de tratamiento para cada riesgo identificado. 47 2. Planes de mitigación de riesgos. 3. Planes de contingencia. 4. Lista de aquellos que son responsables de seguir y tratar cada riesgo. Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Determinar los niveles y los umbrales que definen cuándo un riesgo pasa a ser inaceptable y activa la ejecución de un plan de mitigación de riesgos o un plan de contingencia. 2. Identificar a la persona o al grupo responsable de tratar cada riesgo. 3. Determinar los costes y los beneficios de la implementación del plan de mitigación de riesgos para cada riesgo. 4. Desarrollar un plan general de mitigación de riesgos para el proyecto a fin de organizar la implementación de los planes individuales de mitigación y de contingencia de los riesgos. 5. Desarrollar planes de contingencia para los riesgos críticos seleccionados en caso de que tengan lugar sus impactos. 3.1.1.2.10 PRÁCTICA ESPECÍFICA 3.2: IMPLEMENTAR LOS PLANES DE MITIGACIÓN DE RIESGOS “Monitorizar el estado de cada riesgo periódicamente e implementar el plan de mitigación de riesgos según sea apropiado” (Carnegie Mellon University, 2010). Tomar acciones de forma anticipada para evitar que se materialice un riego es la mejor forma de tener un proyecto saludable, para lograrlo se debe contar un plan de monitoreo de riesgos, que permita conocer el estado de los diferentes riesgos identificados e identificar nuevos. Algunos productos de trabajo que se producirán son: 1. Listas actualizadas del estado del riesgo. 2. Evaluaciones actualizadas de la probabilidad, consecuencia y umbrales de los riesgos. 3. Listas actualizadas de las opciones de tratamiento de riesgos. 4. Listas actualizadas de las acciones tomadas para tratar los riesgos. 5. Planes de mitigación de riesgos para las opciones de tratamiento del riesgo. Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Monitorizar el estado del riesgo. 48 2. Proporcionar un método de seguimiento de los elementos de acción de tratamiento de riesgos abiertos hasta su cierre. 3. Invocar las opciones seleccionadas de tratamiento del riesgo cuando los riesgos monitorizados excedan los umbrales definidos. 4. Establecer un calendario o un período de realización para cada actividad de tratamiento de riesgos que incluya una fecha de inicio y una fecha prevista de finalización. 5. Proporcionar un compromiso continuo de los recursos para cada plan, para que las ejecuciones de las actividades de tratamiento de riesgos tengan éxito. 6. Recoger medidas de rendimiento sobre las actividades de tratamiento de riesgos. 3.1.1.3 DESARROLLO DE REQUISITOS (RD) “El propósito del Desarrollo de Requisitos (RD) es educir, analizar y establecer los requisitos de cliente, de producto y de componente de producto” (Carnegie Mellon University, 2010). Está área de proceso está conformada por 3 objetivos específicos y 10 prácticas especificas distribuidos en sus objetivos específicos. Desarrollar los requisitos es una tarea clave para todo proyecto, debido a que se abordan desde diferentes perspectivas lo que el producto final debe ser, con dichas perspectivas se generan los requisitos, encontrándose 3 tipos principales: requisitos de cliente, requisitos de producto y de componentes de productos. Con estos requisitos adecuadamente recopilados se puede crear de forma eficiente un producto, al considerar apropiadamente las diferentes pruebas a los que serán sometidos, identificando las restricciones que deben cumplirse de acuerdo con el diseño seleccionado. Se deben realizar una serie de actividades para desarrollar dichos requisitos: 1. Educción, análisis, validación y comunicación de las necesidades, las expectativas y las restricciones del cliente para obtener los requisitos priorizados de cliente que constituyen una comprensión de lo que satisfará a las partes interesadas. 2. Recopilación y coordinación de las necesidades de las partes interesadas. 3. Desarrollo de los requisitos del ciclo de vida del producto. 4. Establecimiento de los requisitos funcionales de cliente y de los requisitos de los atributos de calidad. 5. Establecimiento de los requisitos iniciales de producto y de componente de producto consistentes con los requisitos de cliente. 49 Los requisitos no se mantienen estáticos y evolucionan durante todo el desarrollo del proyecto, con los requisitos del cliente se obtienen requisitos de producto y de componentes de producto cubriendo la parte de servicio, sistemas de servicios y sus componentes, para sacar el máximo provecho deben comprenderse a cabalidad los requisitos para ello se realizan diferentes análisis los que pueden incluir:  Análisis de necesidades y de requisitos para cada fase del ciclo de vida de producto, incluyendo las necesidades de las partes interesadas relevantes, el entorno de operación y los factores que reflejan las expectativas y la satisfacción globales del cliente y del usuario final, tales como protección, seguridad y asequibilidad.  Desarrollo de un concepto operacional.  Definición de funcionalidad requerida y atributos de calidad. Con las actividades antes mencionadas se logra obtener información valiosa sobre lo que se espera lograr con el producto para ello se separa el producto en sus diferentes funcionalidades y servicios que este puede prestar. Estas actividades deben realizarse de forma repetitiva para alcanzar el mejor detalle posible con lo cual se elaborará un diseño adecuado, identificando las pruebas que deberán realizarse, de esta forma se podrá establecer diferentes características que permitirán evolucionar al producto en el tiempo para adecuarse a las necesidades futuras. Con la realización del listado de actividades antes mencionado se originan requisitos como los siguientes:  Restricciones de varios tipos.  Limitaciones tecnológicas.  Coste y parámetros de coste.  Restricciones de tiempo y parámetros de calendario.  Riesgos.  Consideraciones de cuestiones implícitas, pero no declaradas explícitamente por el cliente o por el usuario final.  Factores introducidos por consideraciones de negocio propias del desarrollador, por normativas y por leyes. 3.1.1.3.1 META ESPECÍFICA 1: DESARROLLAR LOS REQUISITOS DE CLIENTE “Las necesidades, expectativas, restricciones e interfaces de las partes interesadas se recopilan y traducen en requisitos de cliente” (Carnegie Mellon University, 2010). Conocer a cabalidad los requisitos de un proyecto es determinante para el éxito de éste, para ello debe establecerse una 50 comunicación profunda con los diferentes interesados tales como clientes, usuarios finales, proveedores, desarrolladores, personal de pruebas, fabricantes, personal de soporte logístico, de quienes se podrán obtener sus expectativas las cuales serán traducidas a requerimientos. Los diferentes actores interesados en el proyecto tienen sus propias expectativas y éstas a su vez pueden complementarse o estar en conflicto unas con otras o no existe una claridad en la identificación de éstas; para solventar dicha situación y tener claridad y comprensión sobre los requerimientos se aplica un proceso iterativo durante la ejecución del proyecto para lograr tal fin. Además, se involucran a más interesados con la finalidad que aporten ideas para dilucidar los requerimientos proporcionando un entorno que facilite la interacción y la discusión de ideas. 3.1.1.3.2 PRÁCTICA ESPECÍFICA 1.1: EDUCIR LAS NECESIDADES “Educir las necesidades, las expectativas, las restricciones y las interfaces de las partes interesadas para todas las fases del ciclo de vida del producto” (Carnegie Mellon University, 2010). Con esta práctica se busca extraer y tener claridad sobre las necesidades que tienen los diferentes interesados sobre el proyecto, para lo cual se deberá hacer uso de diferentes herramientas tales como:  Demostraciones de tecnología.  Grupos de trabajo de control de la interfaz.  Grupos de trabajo de control técnico.  Revisiones intermedias del proyecto.  Cuestionarios, entrevistas y escenarios (operacional, soporte y desarrollo) obtenidos de los usuarios finales.  Tutoriales (Walthroughs) de soporte, desarrollo y de operación, y análisis de tareas de usuario final.  Talleres (Workshops) con las partes interesadas para la reducción de los atributos de calidad.  Prototipos y modelos.  Tormenta de ideas También se requiere de fuentes de requisitos que pueden no ser identificadas por el cliente como, por ejemplo:  Políticas de negocio.  Estándares. 51  Decisiones y principios de diseño de arquitectura previos.  Requisitos de entorno de negocio (p. ej., laboratorios, pruebas y otras instalaciones, infraestructura de tecnología de información). Algunos productos de trabajo que se producirán son: 1. Resultados de las actividades de educción de requisitos. Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Comprometer a las partes interesadas relevantes usando métodos para educir las necesidades, las expectativas, las restricciones y las interfaces externas. 3.1.1.3.3 PRÁCTICA ESPECÍFICA 1.2: TRASFORMAR LAS NECESIDADES DE LAS PARTES INTERESADAS EN REQUISITOS DE CLIENTE “Transformar las necesidades, las expectativas, las restricciones y las interfaces de las partes interesadas en requisitos de cliente priorizados” (Carnegie Mellon University, 2010). Las diferentes necesidades y expectativas del cliente, independiente de la fuente, debe ser sometidos a una revisión y análisis con la finalidad de identificar a los que entran en conflicto para realizar una depuración y transformarlos en requisitos útiles para el proyecto. Algunos productos de trabajo que se producirán son: 1. Requisitos de cliente priorizados. 2. Restricciones de cliente para llevar a cabo la verificación. 3. Restricciones de cliente para llevar a cabo la validación. Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Traducir las necesidades, las expectativas, las restricciones y las interfaces de las partes interesadas en requisitos documentados del cliente. 2. Establecer y mantener una priorización de los requisitos funcionales de cliente y de los atributos de calidad. El alcance de un proyecto se establece a través de la priorización de sus requisitos, además permite identificar las iteraciones que tendrá durante su ejecución, además asegura que se traten oportunamente los requisitos funcionales y atributos de calidad que son críticos para el cliente y otras partes interesadas. 3. Definir las restricciones para la verificación y la validación. 52 3.1.1.3.4 META ESPECÍFICA 2: DESARROLLAR LOS REQUISITOS DE PRODUCTO “Los requisitos de cliente se refinan y elaboran para desarrollar los requisitos de producto y de componente de producto” (Carnegie Mellon University, 2010). Identificar los “requisitos de producto y de componente de producto” es crucial para la ejecución del proyecto para lograrlo se debe realizar un análisis sobre los requisitos del cliente. Los requisitos de producto y componente dan la pauta de la forma en que se ejecutará el proyecto, identificando las necesidades en cada una de las etapas del ciclo de vida del producto, la identificación de los diferentes requisitos sirve para asignárselo a personas, tecnología, procesos, iteraciones con la finalidad de garantizar que se cumplan en cada uno de los componentes mencionados. 3.1.1.3.5 PRÁCTICA ESPECÍFICA 2.1: ESTABLECER LOS REQUISITOS DE PRODUCTO Y DE COMPONENTE DE PRODUCTO “Establecer y mantener los requisitos de producto y de componente de producto, basados en los requisitos de cliente” (Carnegie Mellon University, 2010). Los requisitos del cliente deben estar en un lenguaje natural del negocio, para luego transformarlos en especificaciones técnicas asociados al producto y componentes de producto. Todos los requisitos que se originen de forma directa o indirecta deben buscar satisfacer el requerimiento del negocio. Algunos productos de trabajo que se producirán son: 1. Requisitos derivados. 2. Requisitos de producto. 3. Requisitos de componente de producto. 4. Requisitos de arquitectura, que especifican o restringen las relaciones entre componentes de producto Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Desarrollar los requisitos en los términos técnicos necesarios para el diseño del producto y de los componentes de producto. 2. Inferir los requisitos resultantes de las decisiones de diseño. 3. Desarrollar los requisitos de arquitectura capturando los atributos críticos de calidad y las medidas de atributos de calidad necesarios para establecer la arquitectura y el diseño del producto. 53 4. Establecer y mantener las relaciones entre los requisitos para su consideración durante la gestión del cambio y la asignación de los requisitos. 3.1.1.3.6 PRÁCTICA ESPECÍFICA 2.2: ASIGNAR LOS REQUISITOS DE COMPONENTE DE PRODUCTO “Asignar los requisitos para cada componente de producto” (Carnegie Mellon University, 2010). Alcanzar un buen desarrollo de un producto es primordial en todo proyecto, con este propósito se deben asignar los requisitos de productos a los diferentes componentes de producto lo cual se logra al tener una arquitectura de producto definida, presentándose situaciones donde un requerimiento podría generar un atributo de calidad que puede recaer sobre diferentes componentes de producto para lo cual se puede optar por la asignación del atributo de calidad a nivel de arquitectura o se puede dividir y recaer sobre los diferentes componentes, esto dependerá de cada caso. Algunos productos de trabajo que se producirán son: 1. Hojas de asignación de requisitos. 2. Asignaciones provisionales de requisitos. 3. Restricciones de diseño. 4. Requisitos inferidos. 5. Relaciones entre requisitos inferidos. Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Asignar los requisitos a las funciones. 2. Asignar los requisitos a los componentes de producto y a la arquitectura. 3. Asignar las restricciones de diseño a componentes de producto y a la arquitectura. 4. Asignar requisitos a las entregas incrementales. 5. Documentar las relaciones entre requisitos asignados. 3.1.1.3.7 PRÁCTICA ESPECÍFICA 2.3: IDENTIFICAR LOS REQUISITOS DE INTERFAZ “Identificar los requisitos de interfaz” (Carnegie Mellon University, 2010). Al tener conocimientos sobre las diferentes interfaces que se generan entre las funciones del producto se podrán crear soluciones alternativas; el área de proceso Solución Técnica profundiza sobre el tema. Algunos productos de trabajo que se producirán son: 1. Requisitos de interfaz. 54 Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Identificar las interfaces tanto externas como internas al producto 2. Desarrollar los requisitos para las interfaces identificadas. 3.1.1.3.8 META ESPECÍFICA 3: ANALIZAR Y VALIDAR LOS REQUISITOS “Los requisitos se analizan y validan” (Carnegie Mellon University, 2010). Es importante analizar y validar los requisitos para dimensionar los efectos de éstos en el desarrollo del proyecto debido a que se ven involucrados componentes del negocio, expectativas e interfaces. En este análisis se establecen atributos de calidad y la funcionalidad requerida, todo ello en concordancia con las necesidades del negocio. 3.1.1.3.9 PRÁCTICA ESPECÍFICA 3.1: ESTABLECER LOS CONCEPTOS Y LOS ESCENARIOS DE OPERACIÓN “Establecer y mantener los conceptos y los escenarios de operación asociados” (Carnegie Mellon University, 2010). Para tener claridad sobre el comportamiento, uso o desarrollo de un producto es necesario explicar los diferentes eventos que se pueden presentar ya sea en forma secuencial o simultánea, a ésto se le denomina escenario; en cambio “un concepto operacional para un producto depende generalmente tanto de la solución de diseño como del escenario” (Carnegie Mellon University, 2010). Tanto los escenarios como los conceptos ayudan a documentar la interacción de los componentes de producto con su entorno, con otros componentes de producto, con los usuarios. Algunos productos de trabajo que se producirán son: 1. Concepto operacional. 2. Desarrollo, instalación, operación, mantenimiento y conceptos de soporte del producto o componente de producto. 3. Conceptos de retirada. 4. Casos de uso. 5. Escenarios de cronología. 6. Nuevos requisitos. Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Desarrollar los conceptos y los escenarios de operación que incluyan operaciones, instalación, desarrollo, mantenimiento, soporte y retirada según sea apropiado. 55 2. Definir el entorno en el que funcionará el producto o componente de producto, incluyendo los límites y las restricciones. 3. Revisar los conceptos y los escenarios de operación para refinar y descubrir requisitos. 4. Desarrollar un concepto de operación detallado, a medida que se seleccionan los productos y los componentes de producto, que define la interacción del producto, del usuario final y del entorno, y que satisfaga las necesidades operativas, de mantenimiento, de soporte y de retirada. 3.1.1.3.10 PRÁCTICA ESPECÍFICA 3.2: ESTABLECER UNA DEFINICIÓN DE LA FUNCIONALIDAD Y DE LOS ATRIBUTOS DE CALIDAD REQUERIDOS “Establecer y mantener una definición de funcionalidad y de los atributos de calidad requeridos” (Carnegie Mellon University, 2010). Comprender a cabalidad lo que se espera que haga el producto es parte primordial de un proyecto, para ello se realiza un análisis en el cual se simula el comportamiento que tendrá el producto según las entradas y salidas que podría recibir, con ello se puede vincular los requisitos con las funciones lógicas a lo cual se le denomina arquitectura funcional. Algunos productos de trabajo que se producirán son: 1. Definición de funcionalidad y de atributos de calidad requeridos. 2. Arquitectura funcional. 3. Diagramas de actividad y casos de uso. 4. Análisis orientado a objetos con servicios o métodos identificados. 5. Requisitos de los atributos de calidad significativos para la arquitectura. Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Determinar la misión clave y los factores de negocio. 2. Identificar la funcionalidad y los atributos de calidad deseados. 3. Determinar los atributos de calidad significativos para la arquitectura en base a la misión clave y los factores del negocio. 4. Analizar y cuantificar la funcionalidad requerida por los usuarios finales. 5. Analizar los requisitos para identificar las particiones lógicas o funcionales (p. ej., subfunciones). 56 6. Dividir los requisitos en grupos, en base a los criterios establecidos (p. ej., funcionalidad similar, requisitos similares de atributos de calidad, acoplamiento) para facilitar y enfocar el análisis de requisitos. 7. Asignar los requisitos de cliente a las particiones funcionales, objetos, personal o elementos de soporte para dar apoyo a la síntesis de las soluciones. 8. Asignar los requisitos a las funciones y a las subfunciones (u otras entidades lógicas). 3.1.1.3.11 PRÁCTICA ESPECÍFICA 3.3: ANALIZAR LOS REQUISITOS “Analizar los requisitos para asegurarse que son necesarios y suficientes” (Carnegie Mellon University, 2010). Dentro de un proyecto existen diferentes tipos de requisitos, requisitos de nivel bajo o nivel uno, hasta requisitos de primer nivel, requisitos de seguimiento, los cuales deben estar orientados a lograr los objetivos del proyecto, para ello, se debe analizar si son necesarios y suficientes para alcanzar el objetivo, dicho análisis se debe realizar a medida que se construyen los requisitos. Algunos productos de trabajo que se producirán son: 1. Informes de defectos de los requisitos. 2. Cambios propuestos a los requisitos para resolver defectos. 3. Requisitos clave. 4. Medidas de rendimiento técnico. Sub práctica. Para obtener las herramientas de los productos esperados, se deben realizar las siguientes sub-prácticas: 1. Analizar las necesidades, las expectativas, las restricciones y las interfaces externas de las partes interesadas para organizarlas en temas relacionados y eliminar conflictos. 2. Analizar los requisitos para determinar si satisfacen los objetivos de los requisitos de nivel más alto. 3. Analizar los requisitos para asegurarse que son completos, factibles, realizables y verificables. 4. Identificar los requisitos clave que tienen una fuerte influencia en el coste, el calendario, el rendimiento o el riesgo. 5. Identificar las medidas técnicas de rendimiento que serán seguidas durante el esfuerzo de desarrollo. 6. Analizar los conceptos y los escenarios de operación para refinar las necesidades, las restricciones y las interfaces del cliente, y para inferir nuevos requisitos. 57 3.1.1.3.12 PRÁCTICA ESPECÍFICA 3.4: VALIDAR LOS REQUISITOS “Analizar los requisitos para equilibrar las necesidades y las