Diseño de una metodología para el mantenimiento de software basado en el modelo Cmmi y Scrum para una empresa SAAS

Texto completo

(1)UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERIA. PROYECTO DE TRABAJO DE GRADO. DISEÑO DE UNA METODOLOGÍA PARA EL MANTENIMIENTO DE SOFTWARE BASADO EN EL MODELO CMMI Y SCRUM PARA UNA EMPRESA SaaS. LEONARDO SAPUY CELIS. DIRECTOR: VICTOR HUGO MEDINA. BOGOTÁ D.C., 2019. 1.

(2) NOTAS DE ACEPTACIÓN ________________________________________ ________________________________________ ________________________________________ ________________________________________ ________________________________________. 2.

(3) AGRADECIMIENTOS A mi familia, por el inmenso apoyo recibido durante el tiempo de estudio, por sus consejos, sus palabras y toda la motivación recibida que me han permitido llegar hasta esta instancia. A mi novia, por todas las palabras de aliento, la paciencia durante todo este tiempo y las horas que posiblemente dejé de dedicarle mientras me dedicaba a mis estudios. Al entorno universitario, incluyendo compañeros, por la ayuda recibida, por por los comentarios y retroalimentaciones, por el apoyo recibido durante esta etapa, también a los profesores por la dedicación con las revisiones, los consejos brindados y la guía durante todo este proceso.. 3.

(4) CONTENIDO RESUMEN. 10. INTRODUCCIÓN. 11. 1.. 13. CAPÍTULO I: DESCRIPCIÓN DE LA INVESTIGACIÓN. 1.1.. PLANTEAMIENTO DEL PROBLEMA. 13. 1.2.. OBJETIVOS. 13. 1.2.1. OBJETIVO GENERAL. 13. 1.2.2. OBJETIVOS ESPECÍFICOS. 13. 1.3.. JUSTIFICACIÓN. 14. 1.4.. HIPOTESIS. 14. 1.5.. ALCANCE, LIMITACIONES Y RESULTADOS ESPERADOS. 15. 1.5.1. Alcance. 15. 1.5.2. limitaciones. 15. 1.5.3. Resultados esperados. 15. 1.6.. 16. MÉTODOLOGIA DE INVESTIGACIÓN. 1.6.1. Adquisición de conocimiento. 16. 1.6.2. Diseño. 16. 1.6.3. Afinación. 16. 1.7.. 16. 2. 2.1.. ORGANIZACIÓN DEL TRABAJO DE GRADO CAPÍTULO II: FUNDAMENTACIÓN TEÓRICA MARCO TEÓRICO. 18 18. 2.1.1. CMMI. 18. 2.1.2. CMMI Development 2.0. 23. 2.1.3. SCRUM. 24. 2.1.4. KANBAN. 25. 2.1.5. SCRUMBAN. 27. 2.2.. 27. MARCO CONCEPTUAL. 4.

(5) 3.. CAPÍTULO III: ADQUISICIÓN DE CONOCIMIENTO. 29. 3.1.. INFORMACIÓN RECOLECTADA.. 29. 3.2.. ANÁLISIS DE LA ESTRATEGIA DE LA EMPRESA OBJETO DE ESTUDIO. 29. 3.3.. ANÁLISIS DE LA ESTRUCTURA ORGANIZACIONAL DEL ÁREA. 29. 3.4.. ANÁLISIS DE LAS METODOLOGÍAS DE DESARROLLO DE SOFTWARE. 30. 3.5.. ANÁLISIS DE LOS PROCESOS DE MANTENIMIENTO DE SOFTWARE. 30. 3.6.. ANÁLISIS DE ESTÁNDARES DE CALIDAD USADOS. 31. 4.. CAPÍTULO IV: DISEÑO DE LA METODOLOGIA. 33. 4.1.. METODOS DE EVALUACIÓN – CMMI. 33. 4.2.. EVALUACIÓN INICIAL. 34. 4.2.1. Prerrequisitos y planeación del diagnóstico. 36. 4.2.2. Ejecución del Diagnóstico. 38. 4.3.. 41. IMPLEMENTACIÓN DE CMMI. 4.3.1. Iniciar. 42. 4.3.2. Diagnosticar. 42. 4.3.3. Establecer. 42. 4.3.4. Ejecutar. 43. 4.3.5. Aprender. 43. 4.4.. 43. Definición de modelo de mejoramiento. 4.4.1. Establecer prioridades. 44. 4.4.2. Definir la estrategia de implementación. 45. 4.4.3. Planear las acciones a seguir. 45. 4.4.4. Establecer el plan. 47. 4.5.. implementación. 47. 4.6.. Integración con Scrum. 48. 4.7.. integrando scrum y kanban: scrumban. 50. 4.8.. mejora continua. 51 5.

(6) 4.9. 5.. Evidencias para CMMI CAPITULO V: CONCLUSIONES. 52 53. 5.1.. VERIFICACIÓN, CONTRASTE Y EVALUACIÓN DE LOS OBJETIVOS. 53. 5.2.. SINTESIS DE LA METODOLOGÍA. 53. 6. 6.1. 7.. CAPITULO VI: PROSPECTIVA DEL TRABAJO DE GRADO LINEAS DE INVESTIGACIÓN FUTURAS BIBLIOGRAFIA Y REFERENCIAS BIBLIOGRAFICAS. 55 55 56. 7.1.. REFERENCIAS BIBLIOGRAFICAS. 56. 7.2.. BIBLIOGRAFIA. 58. 6.

(7) INDICE DE FIGURAS Figura 1. Niveles de madurez. 20. Figura 2. Niveles vs. Áreas de proceso CMMI. 22. Figura 3: Niveles de madurez en CMMI V2.0. 23. Figura 4: Ciclo de vida SCRUM. 25. Figura 5: Metodología de diagnóstico. 36. Figura 6: Etapas de ejecución de diagnóstico inicial. 38. Figura 7: Flujo de trabajo de SCRUM mapeado a CMMI-DEV. 49. Figura 8: Tablero Scrumban. 51. 7.

(8) INDICE DE TABLAS Tabla 1. Áreas de Proceso de CMMI. 21. Tabla 2: Métodos SCAMPI. 34. Tabla 3: Relación entre SCRUM y CMMI. 39. 8.

(9) INDICE DE ANEXOS Anexo 1: Mision y Vision Anexo 2: Organigrama. 9.

(10) RESUMEN Para este proyecto se plantea la elaboración del diseño de una metodología que permita a la empresa objeto de estudio, realizar mantenimiento al software que provee a distintos clientes bajo la estrategia SaaS (Software as a Service), todo esto, bajo el modelo Capability Maturity Model Integration (CMMI) complementado con SCRUM como marco de desarrollo ágil. Al finalizar el proyecto, se entregará una metodología que permita a la empresa, modificar sus procesos y procedimientos de tal manera que pueda adoptar el modelo CMMI en su área de mantenimiento, buscando optimizar los recursos y mejorar la operación del área en función de apoyar el cumplimiento de los objetivos estratégicos de la organización. PALABRAS CLAVE: Scrum, CMMI, Capability Maturity Model Integration, desarrollo de software, mantenimiento de software, metodología.. 10.

(11) INTRODUCCIÓN Las empresas SaaS han venido en creciendo en los últimos años pues son un modelo atractivo por costos y por el hecho de poder transferir responsabilidades a terceros, éstas se encargan de proveer software como servicio: cuentan con su propia infraestructura tecnológica, y dan el soporte lógico a los datos y al software. Son ellos quienes se encargan de hacer el mantenimiento al software, asegurar la operación diaria y brindar el soporte tanto al cliente como a los usuarios finales (para software B2C). Por otro lado, el desarrollo de software se ha convertido en una de las tareas de moda en gran parte de las empresas, pues la masificación del internet, los smartphones y los computadores, hacen que la gente deba usar software hasta en sus labores diarias. Para el desarrollo de software, se tienen varias metodologías, unas buscan agilizar el proceso, otras buscan la calidad y la conformidad del cliente, pero entre todas destaca Scrum, el cual es probablemente el marco de desarrollo ágil más usado en desarrollo de software; Scrum funciona bastante bien cuando el alcance es muy variable, o se requiere un software incremental que pueda ser usado desde sus primeras etapas. Luego de tener el software desarrollado, se debe alcanzar una etapa de madurez en los procesos de desarrollo de nuevas funcionalidades y en el mantenimiento de éste, es allí donde entra CMMI a jugar un papel importante, pues es donde las empresas SaaS deberán fortalecerse, siendo éste su “core de negocio”. El modelo CMMI es un modelo que agrupa las mejores prácticas para la mejora y evaluación de los procesos de desarrollo, mantenimiento y operación del software. Lograr integrar estos 2 últimos elementos es un reto para las empresas, pues si bien Scrum es de fácil implementación, muy poco se usa para el mantenimiento del software, y por otro lado, CMMI propone un conjunto de prácticas a ser evaluadas para el mantenimiento y desarrollo, pero no especifica como hacerlo, por lo que se suelen usar otras metodologías o alternativas para el mantenimiento de software que no son muy eficaces, y con las que se debe convivir hasta la obsolescencia del software, pues son tareas del día a día que no tienen un final definido. Alinear un modelo de mejores prácticas para el mantenimiento de software, junto con una metodología o marco de desarrollo ágil, supondría para la empresa una mejora sustancial en sus procesos de mantenimiento, optimizar tiempos de entrega, controlar y asegurar la. 11.

(12) calidad de este; siendo el mantenimiento de software un componente vital en aquellas compañías que se dedican a distribuir o vender software como un servicio. Es por esto, que se propone diseñar una metodología que le permita a las empresas integrar el modelo CMMI junto con SCRUM; siendo la empresa objeto de estudio una compañía que se encarga de proveer software bancario para acceso digital a sus usuarios finales, lo que implica el uso masivo del software, ocurrencia de un sinfín de bugs, cientos de mejoras que se pueden hacer, y bastantes vulnerabilidades por mitigar. Asegurar la calidad de estos procesos con un modelo destinado para tal fin y que se pueda evaluar posteriormente, significaría una mejora sustanciosa en los procesos de mantenimiento del producto de la organización, pues si tenemos en cuenta sus objetivos de humanizar la relación entre el banco y sus usuarios, se debe poner especial cuidado en cómo se mantiene el software que permitiría humanizar esta relación. Como resultado del proyecto se propondrá una metodología que permita evaluar el estado actual de la empresa frente a sus procesos de mantenimiento de software, le ayudará a escoger el conjunto de mejores prácticas que apliquen para cada compañía tomando el modelo CMMI como base y definiendo la hoja de ruta para integrarse con Scrum como marco de desarrollo ágil, dejándola lista para evaluar la operación luego de la implementación del modelo y verificando el estado antes y después de la implementación.. 12.

(13) 1. CAPÍTULO I: DESCRIPCIÓN DE LA INVESTIGACIÓN 1.1. PLANTEAMIENTO DEL PROBLEMA Actualmente, en la empresa objeto de estudio, el área de mantenimiento de software juega un papel bastante importante tanto en el cumplimiento de los objetivos estratégicos de la organización, como en la satisfacción del cliente y del usuario final, sin embargo, la masificación que tiene el software proveído hacia los bancos, implica que sea éste software uno de los canales de atención más importante para el banco, llegando a cerca de 8 millones de usuarios distintos al año, con una concurrencia de más de 400.000 usuarios simultáneos, convirtiéndose el área de mantenimiento el principal motor que garantice el uso del software y la satisfacción de los usuarios. Así mismo, a nivel contractual se tienen multas por incumplimiento de indicadores, siendo el número de defectos y la resolución de los mismos uno de estos indicadores que podrían acarrear en castigos económicos severos para la compañía, por lo que adoptar un modelo de buenas prácticas que optimice los tiempos de respuesta frente a los defectos y garantice el cumplimiento de indicadores representa un objetivo primordial para el área. En la actualidad la empresa objeto de estudio trata de implementar Scrum como metodología de desarrollo, sin embargo, no es suficiente para asegurar el cumplimiento de los indicadores, adicional, en ocasiones se pierde el control sobre la calidad y se inyectan errores o falencias de código.. 1.2. OBJETIVOS 1.2.1. OBJETIVO GENERAL Diseñar una metodología para el mantenimiento de software basado en el modelo CMMI y complementado con Scrum, que optimice los recursos de las áreas encargadas para tal fin en empresas que distribuyan software como servicio. 1.2.2. OBJETIVOS ESPECÍFICOS 1. Definir un criterio de evaluación de madurez 2. Identificar el nivel de madurez actual del área de mantenimiento 3. Diseñar la metodología para implementación de modelo CMMI en el área 13.

(14) 4. Integrar Scrum como marco de desarrollo ágil para la operación 5. Dictar lineamientos y recomendaciones para la aplicación de la metodología. 1.3. JUSTIFICACIÓN La empresa objeto de estudio busca mejorar, optimizar y controlar el proceso de mantenimiento que realiza a sus productos de software, los cuales vende bajo el concepto SaaS a bancos en distintos países de Latinoamérica, implementado un modelo de buenas prácticas que a su vez optimice el proceso de desarrollo bajo una metodología ágil. Debido a que se diseñará una metodología para la aplicación de lo anterior, se encuentra una justificación de tipo metodológica para el desarrollo de este proyecto. Esta metodología deberá apoyar el área en los siguientes aspectos: 6. Mejorar los tiempos de respuesta en cuanto a solución de defectos se refiere 7. Controlar la calidad del producto, mediante la implementación de estándares y modelos de buenas prácticas 8. Medir y cuantificar el estado actual de madurez de los procesos de mantenimiento, para posteriormente iniciar la mejora de estos. 9. Definir un marco de trabajo para el área, bajo el cual se pueda ajustar a las necesidades propias de la organización 10. Apoyar en el cumplimiento de los objetivos tanto del área como de la compañía. 1.4. HIPOTESIS Aun cuando es un proyecto con justificación de tipo metodológica, se define una hipótesis a manera de actividad educativa, pues con el proyecto no se pretende demostrar nada, sino definir una metodología cuya posterior implementación sí podría demostrar la siguiente afirmación: “La implementación de una metodología basada en un modelo de buenas prácticas como CMMI permite al área evaluar la madurez de sus procesos y posteriormente identificar mejoras que se puedan aplicar a sus procesos para optimizar el uso de sus recursos operacionales, adicional si se combina con un marco de desarrollo ágil, se mejoran los tiempos de entrega y con estos, los indicadores de gestión y mantenimiento”. 14.

(15) 1.5. ALCANCE, LIMITACIONES Y RESULTADOS ESPERADOS A continuación, se describe el alcance, las limitaciones y el resultado esperado para la empresa objeto de estudio con el desarrollo de este proyecto. 1.5.1. Alcance Con el desarrollo de este proyecto, se diseñará una metodología capaz de implementar un modelo de madurez CMMI para el desarrollo y mantenimiento de software en organizaciones dedicadas en vender Software como servicio, adicional, se indicará el cómo se debería usar Scrum acorde a estos niveles de madurez para que sea este modelo ágil de desarrollo quien ayude a mantener y potencializar el modelo CMMI. 1.5.2. limitaciones Las limitaciones para el desarrollo de este proyecto están dadas por 2 factores: tiempo y disponibilidad de la información. Se contempla un tiempo aproximado de 9 meses para el desarrollo del proyecto, y aunque se plantea diseñar una metodología completa, es posible que factores importantes como seguimiento, control a la metodología, evaluación y aspectos de mejora no puedan ser contemplados para el documento final en este tiempo. Por otro lado, al ser la empresa objeto de estudio, una compañía dedicada a temas de banca digital, existen unos altos protocolos para el manejo y la confidencialidad de la información, por lo que es muy posible que haya información a la que no se pueda tener acceso, lo que pueda generar vacíos de conocimiento en ciertos aspectos al momento de diseñar la metodología 1.5.3. Resultados esperados Con el diseño de la metodología, se da pie para que la empresa objeto de estudio logre implementar un modelo de madurez en sus procesos de desarrollo de software, el cual, al ser su core de negocio, proporciona un alto nivel de calidad en el desarrollo de sus productos. De esta manera, se convertiría en una empresa más competitiva, los costos se vuelven más predecibles y controlables, los proyectos presentan menos desviaciones de cronograma, lo que sin duda se redunda en un factor diferenciador con las empresas competidoras del sector [1].. 15.

(16) 1.6. MÉTODOLOGIA DE INVESTIGACIÓN Para poder diseñar la metodología objeto de desarrollo no se tiene un marco de trabajo común aplicable. Sin embargo se pueden usar estrategias de implementación del modelo CMMI basados en QualDev-Software Process Improvement (SPI). De esta manera se plantean 3 etapas a manera de metodología para el desarrollo del proyecto, exceptuando la etapa de inicio y planeación, la cual se encuentra implícita en el desarrollo del proyecto: 1.6.1. Adquisición de conocimiento Como primera fase se investigará todo lo concerniente al modelo de madurez CMMI, marco de desarrollo Scrum y conocimiento del área y/o proceso de mantenimiento de software de la empresa objeto de estudio, con eso se tendrá un contexto amplio y suficiente, que permita realizar el desarrollo de la metodología. 1.6.2. Diseño Ya en esta fase, se empieza a idear la metodología de implementación de un modelo CMMI, complementado con Scrum, basados en SPI y modelo IDEAL se propondrá la metodología objeto de este proyecto. 1.6.3. Afinación En la última fase se hará una socialización de la metodología al área de mantenimiento de la empresa objeto de estudio, así mismo se harán retroalimentaciones y correcciones a la metodología que permitan afinar lo planteado con ayuda de todo el equipo involucrado.. 1.7. ORGANIZACIÓN DEL TRABAJO DE GRADO Ya con la realización del proyecto, el trabajo final constaría de la siguiente estructura, desglosada de la siguiente manera: Primero se presentará el resumen y la introducción del trabajo, en el cual se encuentran contempladas las generalidades y una breve contextualización al desarrollo de la investigación. Capítulo 1: Será la descripción del proyecto, encontramos los objetivos, la justificación, la hipótesis, planteamiento del problema, organización entre otros.. 16.

(17) Capítulo 2: Encontraremos la fundamentación teórica del proyecto siendo esta la base con la que se hará la investigación. Capitulo 3: Recopila todo el conocimiento adquirido, la identificación de la empresa objeto de estudio, el análisis que se le hace a la misma y los requerimeintos de información que se le hicieron. Capitulo 4: Aquí se contempla el desarrollo de la investigación y el diseño de la metodología objeto de este trabajo, aboradremos primero como realizar el diagnóstico incial de la empresa, como realizar la implementación de CMMI y como poder integrar SCRUM y Kanban a ese proceso. Capitulo 5: Compone la parte final del documento, endonde encontraremos las conclusiones, los trabajos futuros y demás. 17.

(18) 2. CAPÍTULO II: FUNDAMENTACIÓN TEÓRICA 2.1. MARCO TEÓRICO Todas las bases teóricas de este proyecto consisten en conocer profundamente el modelo CMMI y su evaluación, así como Scrum; para posteriormente verificar su aplicación en integración en áreas de mantenimiento de software de empresas SaaS. 2.1.1. CMMI Capability Maturity Model Integration, por sus siglas en inglés CMMI, se refiere a los modelos que contienen las mejores prácticas, las cuales ayudan a las compañías en la mejora de sus procesos [2]. Estos modelos han sido desarrollados por equipos de trabajo formados por especialistas de la industria, el gobierno y el Software Engineering Institute (SEI) que transfirió los derechos al CMMI Institute para su operación y comercialización [3]. Siendo un modelo refleja una abstracción de la realidad que permite a las organizaciones adoptar prácticas útiles para alcanzar sus objetivos de negocio, constituye una referencia no es un proceso en sí. Para establecer una analogía, querer adaptar la organización al modelo es como si al ver una maqueta de una casa una persona deseara vivir en ella [4]. CMMI fue diseñado para hacer frente a los desafíos del cambiante entorno empresarial mundial, adicional a esto, impulsa el rendimiento empresarial a través de la creación y la evaluación comparativa de capacidades clave [3]. El núcleo de CMMI es un conjunto comprobado de mejores prácticas globales organizadas por capacidades empresariales críticas que mejoran el rendimiento empresarial [4]. Estas capacidades críticas abordan los principales desafíos comunes a cualquier organización, que incluyen: 1. Ingeniería y desarrollo de productos 2. Mejorar el desempeño 3. Desarrollar y mantener la capacidad 4. Gestión de la resiliencia empresarial 5. Planificación y gestión del trabajo 6. Selección y administración de proveedores 7. Garantizar la calidad Administrar la fuerza de trabajo 8. Apoyo a la implementación. 18.

(19) El propósito del modelo es evaluar la madurez de los procesos de una organización y proporcionar una orientación referente a cómo mejorar los procesos que darán lugar a mejores productos. Cuando se habla directamente con personas del SEI, es posible que digan que CMMI es un modelo para la administración de riesgos y que indica la capacidad de una organización para administrar los riesgos. Esta indicación es un indicio de la probabilidad con la que una organización puede cumplir sus promesas o proporcionar productos de alta calidad que sean atractivos para el mercado [2]. Otro enfoque es que el modelo proporciona un buen indicador de cómo actuará una organización en situaciones de estrés. Una organización de gran madurez y altas capacidades afrontará con calma las situaciones inesperadas y de estrés, reaccionará, realizará cambios y seguirá adelante. Una organización con un reducido nivel de madurez y pocas capacidades tenderá a dejarse llevar por el pánico en situaciones de estrés, seguirá a ciegas los procedimientos obviados, o bien, desbaratará todos los procesos y volverá al caos [5]. El modelo fue diseñado para que se use como base de las iniciativas enfocadas a mejorar los procesos y, en el ámbito de la evaluación, únicamente como ayuda para medir las mejoras [3]. Este enfoque ha dado lugar a resultados mixtos. Resulta demasiado fácil confundir el modelo con una definición de proceso e intentar seguirlo en lugar de considerarlo como un mapa que identifica las lagunas en los procesos existentes que habría que rellenar. El bloque de creación fundamental del modelo CMMI es un área de proceso que define los objetivos y varias de las actividades que se suelen realizar para lograr dichos objetivos. Un ejemplo de un área de proceso es el control de calidad de los procesos y productos. Otro ejemplo es la administración de las configuraciones. Es importante entender que un área de proceso no es un proceso. Un solo proceso puede atravesar varias áreas de proceso y una sola área de proceso puede abarcar varios procesos [5]. Dentro de los procesos de desarrollo de CMMI, se tienen 2 modelos, CMMI-Dev y CMMIDev + IPPD. Tanto el uno como el otro manejan 6 niveles de madurez para la versión 2.0, empezando desde el nivel 0 hasta el 5, tal y como se representan en la figura 1. De esta manera se establece como nivel 5 el máximo nivel de madurez que puede alcanzar una organización[7].. 19.

(20) Figura 1. Niveles de madurez [2] ●. Nivel 0 - Incompleto: En este nivel las organizaciones y sus procesos de desarrollo funcionan con deficiencia. El trabajo puede o no completarse.. ●. Nivel 1 - Realizado: En el nivel 1 el trabajo se completa, pero a menudo se retrasa y se supera el presupuesto.. ●. Nivel 2 - Administrado: Las empresas en este nivel planean sus proyectos, se ejecutan, se miden y se controlan.. ●. Nivel 3 - Definido: En este nivel las organizaciones poseen estándares que permiten orientar los proyectos, programas y portafolios.. ●. Nivel 4 - Administrado cuantitativamente: las organizaciones en este nivel se basan en datos con objetivos cuantitativos de mejora del rendimiento que son predecibles y se alinean para satisfacer las necesidades de las partes interesadas internas y externas,. ●. Nivel 5 - Optimizar: la organización se centra en la mejora continua y está diseñada para pivotar y responder a las oportunidades y al cambio. La estabilidad de la organización proporciona una plataforma para la agilidad y la innovación.. Estos niveles se pueden evaluar usando métricas como SCAMPI (Standard CMMI Appraisal Method for Process Improvement), el cual es el método oficial para proveer puntos de referencia de sistemas de calificación relacionados con los modelos CMMI. Así mismo se usa para identificar fortalezas y debilidades, revelar riesgos y determinar niveles de capacidad y madurez.. 20.

(21) El modelo CMMI se divide en 22 áreas de proceso, cada una perteneciente a un nivel de madurez [2], como se muestra en la Tabla 1. Acrónimo. Área de procesos. CAR. Análisis y resolución causal. CM. Administración de configuración. DAR. Análisis y resolución de decisiones. IPM. Administración integrada de proyectos. MA. Medida y análisis. OID. Innovación e implementación organizativas. OPD. Definición de procesos organizativos. OPF. Enfoque de los procesos organizativos. OPP. Rendimiento de los procesos organizativos. OT. Aprendizaje organizativo. PI. Integración de productos. PMC. Control y supervisión de proyectos. PP. Planeación de proyectos. PPQA. Control de calidad de procesos y productos. QPM. Administración cuantitativa de proyectos. RD. Definición de requisitos. REQM. Administración de requisitos. RSKM. Administración de riesgos. SAM. Administración de acuerdos con proveedores. 21.

(22) TS. Solución técnica. VER. Comprobación. VAL. Validación Tabla 1. Áreas de Proceso de CMMI. [4]. De esta manera, se tiene que las empresas deben cumplir con distintas metas en todas estas áreas de proceso para poder alcanzar el máximo nivel de CMMI [4]. En el siguiente gráfico se identifica la relación entre niveles y áreas de proceso:. Figura 2. Niveles vs. Áreas de proceso CMMI [2]. Se identifica que si bien, CMMI indica 6 niveles (tomando el nivel 0), solo a partir del 2 nivel es en donde se empieza a apreciar la madurez de los procesos, por lo que para CMMI no tienen validez el nivel 0 y el nivel 1, aunque vale la pena mostrarlos en la escala presentada anteriormente. Cada área de proceso consta de componentes necesarios, esperados e informativos. En realidad, solo se requieren los componentes necesarios para superar una valoración según el modelo. Los componentes necesarios son los objetivos genéricos y específicos de cada área de proceso. Los componentes esperados son los procedimientos genéricos y específicos para cada objetivo genérico o específico. Dado que un componente esperado no es obligatorio, se puede reemplazar un procedimiento genérico o específico por otro equivalente.. 22.

(23) 2.1.2. CMMI Development 2.0 A inicios del 2018, El CMMI Institute lanzó CMMI Development V2.0, un modelo de mejora que especifica las mejores prácticas para el desarrollo de software, productos y sistemas que impulsan el rendimiento empresarial; referente a su pasada versión, esta nueva edición contiene mejoras considerables incluyendo soporte para metodologías ágiles, entre las que encontramos [4]: 9. Enfoque en el rendimiento: Se han implementado nuevas prácticas en todos los niveles de madurez para enfatizar y enfocarse en mejorar el desempeño organizacional. 10. Usabilidad mejorada y orientación integrada: CMMI V2.0 se basa en una arquitectura escalable que permite la integración sin fisuras del nuevo contenido para proporcionar orientación para las necesidades comerciales específicas de la compañía. 11. Más fácil de entender y acceder: CMMI V2.0 ha sido escrito en un lenguaje no técnico; esto hace que sea más accesible para quienes no hablan el inglés y sea más fácil de traducir a otros idiomas. 12. Mejora en los niveles de madurez: respecto a su versión anterior, los niveles de madurez han sido mejorados, para definir el estado de las empresas actuales (ver Figura 3).. Figura 3: Niveles de madurez en CMMI V2.0 [4]. 23.

(24) 2.1.3. SCRUM Scrum es un marco dentro del cual las personas pueden abordar problemas adaptativos complejos, al tiempo que ofrecen productiva y creativamente productos del más alto valor posible. Scrum en sí mismo es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto [6]. Los roles principales en Scrum son el Scrum Master, que procura facilitar la aplicación de scrum y gestionar cambios, el Product Owner, que representa a los stakeholders (interesados externos o internos), y el Team (equipo) que ejecuta el desarrollo y demás elementos relacionados con él [7]. Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo y debe ser lo más corta posible), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar (PBI, Product Backlog Item). Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo dialoga con el Product Owner buscando la claridad y magnitud adecuadas (Cumpliendo el INVEST) para luego determinar la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint [7]. Scrum permite la creación de equipos auto organizados impulsando la co-localización de todos los miembros del equipo, y la comunicación verbal entre todos los miembros y disciplinas involucrados en el proyecto [6]. Principales características de Scrum 13. Gestión regular de las expectativas del cliente, resultados anticipados, flexibilidad y adaptación, retorno de inversión, mitigación de riesgos, productividad y calidad, alineamiento entre cliente y equipo, por último, equipo motivado. 14. Se hace uso de equipos auto-dirigidos y auto-organizados.. 24.

(25) 15. Se realiza a diario una reunión de Scrum, que es una reunión de avance diaria que no dura más de 15 minutos con el objetivo de obtener realimentación sobre las tareas del equipo y los obstáculos que se presentan. En la figura 4 se logra identificar el ciclo de vida de SCRUM, en el cual se especifican las actividades que se hacen durante cada interacción.. Figura 4: Ciclo de vida SCRUM [8]. Cada uno de estos puntos mencionados hacen que el Scrum sea utilizado de manera regular en un conjunto de buenas prácticas para el trabajo en equipo y de esa manera obtener resultados posibles. Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software [9]. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar. Así, si se utiliza una pizarra con notas autoadhesivas cualquier miembro del equipo podrá ver tres columnas: trabajo pendiente (backlog), tareas en proceso (in progress) y hecho (done). De un solo vistazo, una persona puede ver en qué están trabajando los demás en un momento determinado [9]. 2.1.4. KANBAN Definimos Kanban como un método para gestionar el trabajo intelectual, con énfasis en la entrega justo a tiempo, mientras no se sobrecarguen los miembros del equipo. En este enfoque, el proceso, desde la definición de una tarea hasta su entrega al cliente, se muestra para que los participantes lo vean y los miembros del equipo tomen el trabajo de una cola [10].. 25.

(26) En el desarrollo de software, se utiliza el sistema Kanban virtual para limitar el trabajo en curso. A pesar de que el nombre se origina del idioma japonés "Kanban", que se traduce aproximadamente como "tarjeta de señal", y hay tarjetas utilizadas en la mayoría de las implementaciones de Kanban en desarrollo de software, estas tarjetas no funcionan en realidad como señales para realizar más trabajo. Representan los elementos de trabajo. De ahí el término "virtual" porque no existe una tarjeta física. El método Kanban formulado por David J. Anderson es una aproximación al proceso gradual, evolutivo y al cambio de sistemas para las organizaciones. Utiliza un sistema de extracción limitada del trabajo en curso como mecanismo básico para exponer los problemas de funcionamiento del sistema (o proceso) y estimular la colaboración para la mejora continua del sistema. Un ejemplo del sistema de extracción es el sistema Kanban, y es después de esta popular forma de trabajo en curso, que se ha denominado el método [11]. Existe una serie de principios básicos con el fin de obtener el máximo rendimiento de los flujos trabajo. ●. Visualice lo que hace (su flujo de trabajo): una visualización de todas sus tareas y elementos en una tabla contribuirá a que todos los miembros de su equipo se mantengan al corriente con su trabajo.. ●. Limite la cantidad de Trabajo en Proceso (límites del TEP): establezca metas asequibles. Mantenga el equilibrio de su flujo de trabajo mediante la limitación de los trabajos en proceso para prevenir el exceso de compromiso en la cantidad de tareas que será incapaz de terminar.. ●. Realice un seguimiento de su tiempo: El seguimiento del tiempo confluye con la metodología Kanban. Realice un seguimiento de su tiempo de forma contínua y evalúe su trabajo con precisión.. ●. Lectura fácil de indicadores visuales: conozca lo que está ocurriendo de un solo vistazo. Utilice tarjetas de colores para distinguir los Tipos de trabajo, Prioridades, Etiquetas, Fechas límite y más.. ●. Identifique los cuellos de botella y elimine lo que resulta descartable: aproveche al máximo los plazos y ciclos de ejecución, del Flujo Acumulativo y de los informes de tiempo. Estos criterios le permitirán evaluar su rendimiento, detectar los problemas y ajustar el flujo de trabajo en consecuencia. [12]. 26.

(27) 2.1.5. SCRUMBAN Conocemos Kanban y Scrum como metodologías de gestión Agile. Scrumban combina las mejores características de ambos métodos. Reúne la naturaleza preceptiva de Scrum y la capacidad de mejora del proceso de Kanban, permitiendo a los equipos moverse hacia el desarrollo Agile y a mejorar constantemente sus procesos. Scrumban se está haciendo especialmente popular en industrias en las que el desarrollo del proyecto y el mantenimiento van juntos. Scrumban evolucionó a partir de una instancia de Scrum complementado con prácticas básicas Kanban. Estas son: visualización, límites del trabajo en progreso, gestión del flujo de trabajo, y manteniendo políticas explícitas [12]. Los principios básicos de implementación de Scrumban incluyen: ●. Empieza con los tableros y labores que usas ahora.. ●. Está de acuerdo con perseguir la mejora hacia un proceso más efectivo.. ●. Respeta las labores y responsabilidades actuales mientras pretende mejorarlas fácilmente.. 2.2. MARCO CONCEPTUAL Para tener un contexto sobre como diseñar o crear una metodología se realiza consulta de conceptos y términos en literatura, artículos y demás, de conceptos que se mencionan y se tratan en el desarrollo de este proyecto, por lo que es importante conocer a que nos referimos cuando hablamos de CMMI, Scrum, o SaaS. 16. SOFTWARE: se considera que el software es el equipamiento lógico e intangible de un ordenador. En otras palabras, el concepto de software abarca a todas las aplicaciones informáticas, como los procesadores de textos, las planillas de cálculo y los editores de imágenes. El software es desarrollado mediante distintos lenguajes de programación, que permiten controlar el comportamiento de una máquina. Estos lenguajes consisten en un conjunto de símbolos y reglas sintácticas y semánticas, que definen el significado de sus elementos y expresiones. Un lenguaje de programación permite a los programadores del software especificar, en forma precisa, sobre qué datos debe operar una computadora [13].. 27.

(28) 17. MANTENIMIENTO DE SOFTWARE: el mantenimiento de software es la modificación de un producto de software después de la entrega, para corregir errores, mejorar el rendimiento, u otros atributos. El mantenimiento del software es una de las actividades más comunes en la ingeniería de software. El mantenimiento de software es también una de las fases en el ciclo de vida de desarrollo de sistemas (SDLC, sigla en inglés de System Development Life Cycle), que se aplica al desarrollo de software [14]. La fase de mantenimiento es la fase que viene después del despliegue (implementación) del software en el campo. 18. SaaS (Software as a Service): es un modelo de distribución de software en el que tanto el software como los datos manejados son centralizados y alojados en un único servidor externo a la empresa. Esto implica que el software utilizado por la empresa no se encuentra en la misma, sino que un proveedor se ocupa del hosting de dicho software en la nube, así como del mantenimiento y el soporte. La empresa contratante accede al software y todos sus datos a través de un navegador web desde cualquier ordenador. Eso quiere decir que toda la información, procesos, resultados, etc. almacenados en este software son de fácil acceso desde cualquier lugar. Tanto el software como los datos están centralizados y hospedados en un único servidor [15].. 28.

(29) 3. CAPÍTULO III: ADQUISICIÓN DE CONOCIMIENTO 3.1. INFORMACIÓN RECOLECTADA. En este capitulo tenemos toda la información que se logró recolectar sobre la empresa caso de estudio, se usaron técnicas de observación cuando no fue posible obetener. Se obtuvieron los siguientes documentos, porporcionados por la empresa: •. Mision y visión coporativa. •. Mision y vision del area de desarrollo y mantenimiento. •. Objetivos del area. •. Orgranigrama del area. •. Manuales de cargos. •. Procedimientos de desarrollo y mantenimiento. •. Lineas base de calidad. 3.2. ANÁLISIS DE LA ESTRATEGIA DE LA EMPRESA OBJETO DE ESTUDIO Luego de revisar la misión y visión corporativa (Ver Anexo 1) se entiende que la empresa objeto de estudio a corto plazo pretende mejorar la calidad de sus productos, sabiendo que es una empresa SaaS, entendemos que desarrollan software y que adicional a ello, lo ofrecen como servicio, incluyendo infraestructura y soporte. Si bien los objetivos generales no son muy especificos al proyecto, si encontramos los objetivos del área (Ver Anexo 1), teniendo esto, identificamos que uno de sus principales objetivos es aumentar el numero de releases mensuales y disminuir el número de bugs incluidos en cada versión, por lo que aplicar una metodología de desarrollo ágil, sin dejar de lado la calidad del desarrollo es un punto vital en el cumplimiento del mismo, a partir de allí se encuentran razones válidas para que la empresa objeto de estudio se interese en la aplicación de la metodología planteada buscando la consecución de los objetivos.. 3.3. ANÁLISIS DE LA ESTRUCTURA ORGANIZACIONAL DEL ÁREA Revisando el orgranigrama del area (Ver Anexo 2), se encuentra con 2 coordinadores de desarrolloy 1 de mantenimiento quienes supervisan a los desarrolladores. Los 29.

(30) desarrolladores hacen parte de celulas de desarrollo o de equipos de mantenimiento según su rol, los cuales son dirigidos junto con otros recursos de otras areas (seguridad, QA, funcional) por gerentes de proyecto transversales, lo cual nos daría una estrctura matricial fuerte [16], enfocada a proyectos con equipos de trabajos definidos y recursos transversales de otras áreas... 3.4. ANÁLISIS DE LAS METODOLOGÍAS DE DESARROLLO DE SOFTWARE No se logró recopilar documentación oficial de la metodología de desarrollo usada, sin embargo, se ha logrado observar que hay dos bifurcaciones en los equipos de desarrollo. Cuando los requerimientos son cortos (de 2 a 4 meses), se usa metodología Cascada, la cual implica un unico producto al final del tiempo, sin embargo cuando son proyectos de mayor duración, se realizan entregas mensiales o bimensuales de un producto usable, no es netamente SCRUM, pero usa los principios del desarrollo ágil para realizar entregas iterativas de un producto con una funcionalidad incremental; sin embargo, los equipos de mantenimiento no tienen una metodologia definida, pues la carga laboral se basa en el “día a día” y no hay un backlog de requerimientos definidos, adicional deben asegurar el soporte de la operación cuando se tienen defectos en producción, por lo que la aplicación de una metodología de desarrollo organizaría de mejor manera el trabajo de los equipos y por ende la eficacia del mismo.. 3.5. ANÁLISIS DE LOS PROCESOS DE MANTENIMIENTO DE SOFTWARE Según la observación aplicada, se logra establecer que los procesos de mantenimiento de software de la empresa objeto de estudio son realizados por equipos especializados interdisplinares y tranversales pues no solo desarrollo se encuentra involucrado, sino areas de QA, Seguridad, Arquitectura, Proyectos, Service Desk, Operaciones, Relacionamiento, Diseño y Funcional. El equipo de mantenimiento es el encargado de 4 tareas especificas en el siguiete orden de prioridad: 1. Soporte y atención de incidentes en producción que afecten el servicio 2. Resolución de errores en los productos 3. Desarrollo de requerimientos simples 4. Solución de vulnerabilidades de seguridad halladas en los productos. 30.

(31) Para lo anterior se tiene el area de Service Desk, que es quien canaliza las solicitudes cuando son errores de los producots o incidentes en producción, los requerimientos simples se canalizan mediante el area comercial y las vulnerabilidades pueven venir del area tecnica de los clientes o auditorias internas o externas. Todo lo anterior se unifica en forma de tickets en una plataforma de gestion de proyectos, los cuales son notificados al equipo de mantenimiento y son asignados a los distintos desarrolladores, ellos estiman con base en la información recolectada y evidencias adjuntas a cada ticket cada tiempo de desarrollo, y con base en esta estimación se define el alcance la próxima versión en la cual se intricucirán los parches a errores / requerimientos y vulnerabilidades, todo esto se somete a pruebas para verificar el correcto funcionamiento, de esta manera y previa aprobación del cliente, se programa el pase a producción, el cual se encuentra a cargo del equipo de operaciones, son quienes se encargan de subir los distintos productos a los servidores / tiendas de aplicaciones, etc en ambientes beta o preproductivos. Luego de esto el cliente realiza pruebas y da el visto bueno para la masificación de la nueva versión, de esta manera se da por terminada la versión de mantenimiento y se inicia de nuevo el ciclo tomando los tickets que se tengan pendientes en el backlog.. 3.6. ANÁLISIS DE ESTÁNDARES DE CALIDAD USADOS Se logra identificar que todo el proceso de gestión de cambios, service desk y operaciones usan en gran parte ITIL para su gestión, sin embargo, estas areas son foraneas a la específica de desarrollo, la cual solo se logró identificar el uso de 3 herramientas la calidad del desarrollo, pero no se aplica ningún estandar conocido. Las herramientas son las siguientes: 19. Jenkins CI: herramienta de integración continua que permite automatizar procesos de compilación, generación de instaladores, ofuscado, etc. Se integra con distintos plugins añadiendo así funcionalidad, de esta manera se evitan errores al momento generar instaladores y se quitan estos tiempos al desarrollador. [17] 20. SonarQube: es una herramienta para análisis de código fuente, soporta multiples lenguajes y es capaz de analizar distintos estándares de calidad según su configuración. Informa sobre código duplicado, cobertura de codigo, bugs. 31.

(32) conocidos, diseño de software, entre otros [18]. Todo esto con el fin de mejorar la calidad del código. 21. GitFlow: es una variante de GIT, un sistema de versionamiento que permite a los desarrollodares trabajar de forma paralela en un solo proyecto de código pero en requerimientos distintos, permite unificar cambios, deshacer, guardar estados de los archivos entre otros [19]. Si bien se tienen herramientas, no hay una metodología o estandar definido, por lo que lograr integrar CMMI al proceso de desarrollo añadiría ese componente estandar de calidad que busca la compañía para alcanzar sus objetivos estrategicos.. 32.

(33) 4. CAPÍTULO IV: DISEÑO DE LA METODOLOGIA Enesete capitulo desrrollaremos la metodologia basados en la información recopilada de la empresa, junto con la investigación realizada por el autor.. 4.1. METODOS DE EVALUACIÓN – CMMI CMMI define un conjunto de Requerimientos de Evaluacion, señalados en el documento Appraisal Requirements for CMMI (ARC). Muchas organizaciones se esfuerzan en medir su progreso llevando a cabo una evaluación (appraisal) y ganando una clasificación del nivel de madurez o de un nivel de capacidad de logro. Las valoraciones de las organizaciones utilizando un modelo CMMI deben ajustarse a los requisitos definidos en el ARC. La evaluación se enfoca en identificar oportunidades de mejora, y comparar los procesos de la organización con las mejores prácticas CMMI. Los equipos de evaluación usan el modelo CMMI y un método conforme a ARC para guiar su evaluación y reporte de conclusiones. Los resultados de la evaluación son usados para planear mejoras en la organización. Hay tres clases de evaluación: Clase A, B y C. Para ellos se tiene el Standard CMMI Appraisal Method for Process Improvement (SCAMPI), el cual es un Método de evaluación que cumple todos los requerimientos ARC. Una evaluación de clase A es más formal y es la única que puede resultar en una clasificación de nivel [20]. El Standard CMMI Appraisal Method for Process Improvement (SCAMPI) es el método oficial SEI para proveer puntos de referencia de sistemas de calificación en relación con los modelos CMMI. SCAMPI se usa para identificar fortalezas y debilidades de los procesos, revelar riesgos de desarrollo/adquisición, y determinar niveles de capacidad y madurez. Se utilizan ya sea como parte de un proceso o programa de mejoramiento, o para la calificación de posibles proveedores. El método define el proceso de evaluación constando de preparación; las actividades sobre el terreno; observaciones preliminares, conclusiones y valoraciones; presentación de informes y actividades de seguimiento. El más riguroso es el SCAMPI A y es el que permite obtener el nivel de madurez oficial. Una vez superado el SCAMPI A, es común que la organización reciba un diploma acreditativo que indica el nivel de madurez alcanzado, tal como se muestra en la tabla 2. 33.

(34) El SCAMPI A debe ser realizado por una figura denominada Lead Appraiser. El Lead Appraiser es una persona acreditada por el SEI (Software Engineering Institute, organización propietaria del modelo CMMI) para realizar la evaluación CMMI. Finalmente, es el Lead Appraiser quién emite lo que se conoce como “Appraisal Disclosure Statement”, documento que muestra los resultados de la evaluación [21]. Característica. Clase C Provee un amplio rango de opciones, incluyendo diferentes acercamientos a la medición de la implementación de las áreas de procesos, permitiendo una escala definida por la organización.. Clase B Provee opciones al alcance del modelo y de completitud sobre la organización, sin embargo, la implementación de las áreas de proceso se mide de manera fija con una escala, se miden las áreas de proceso en prácticas implementadas en la organización. Clase A Es el método más riguroso, es muy poco flexible y es el único que genera clasificación oficial.. Cantidad de evidencia requerida. Baja. Media. Alta. Genera clasificación oficial. No. No. Sí. Cantidad de recursos requeridos. Baja. Media. Alta. Tamaño del equipo. Pequeño. Mediano. Grande. Descripción. Tabla 2: Métodos SCAMPI [4]. Si bien podríamos definir un estándar de evaluación que cumpla con los requerimientos del ARC, sería innecesario sabiendo que ya existe un estándar avalado y soportado de manera oficial por el SEI para estas evaluaciones. De esta manera se define para la metodología propuesta, el uso de SCAMPI como método de evaluación, tanto de la inicial como de la final.. 4.2. EVALUACIÓN INICIAL Lo primero es poder realizar una evaluación inicial, de esta manera podemos obtener el estado actual de la empresa, lo que nos dará una especie de inventario de procesos existentes los cuales se ajustarán para poder llegar al nivel deseado. 34.

(35) Es necesario entonces contar con un equipo interno que piueda realizar una evaluación SCAMPI Clase C, esto debiedo que es el de menor duración y alcance, y es utilizado para ver el uso de los procesos en la organización y de las iniciativas de mejora con relación al modelo CMMI. Al ser más breve los resultados permiten identificar una tendencia en el uso del proceso. Si bien, esta evaluación Clase C no nos define un nivel de madurez, no puede ayudar con los siguientes puntos: •. Proporcionar un análisis rápido de brechas en el proceso de una organización en relación con el CMMI. •. Evaluar la idoneidad de un nuevo proceso antes de que se implemente. •. Monitorear la implementación de un proceso.. •. Apoyar la selección de un proveedor.. Debido a que existe una amplia latitud en la estructuración de SCAMPI C, los tipos de resultados varían ampliamente. Los resultados reflejan el propósito de la evaluación y con frecuencia incluyen: •. Hallazgos que describen las fortalezas y debilidades de los procesos evaluados. Dependiendo del alcance de la evaluación y la estrategia, los hallazgos se pueden asignar a los componentes CMMI relevantes.. •. Caracterizaciones que resumen la idoneidad de los procesos evaluados con respecto al CMMI.. •. Acciones recomendadas de mejora de procesos.. •. Una base de datos que la organización puede seguir usando para monitorear el progreso de la mejora de procesos y para respaldar evaluaciones futuras.. Al igual que SCAMPI B, el método SCAMPI C se deriva del método SCAMPI A. Las diferencias significativas entre un SCAMPI C y un SCAMPI B incluyen: •. Un SCAMPI C puede tener un alcance en cualquier nivel de la estructura de CMMI, como área de proceso, objetivo o práctica.. •. Los equipos de evaluación pueden ser tan pequeños como una sola persona (es decir, solo para el Evaluador principal).. •. No se requiere la corroboración de los datos ni la validación de los hallazgos (aunque puede ser recomendable en algunos casos).. •. No hay requisitos específicos con respecto a las fuentes de evidencia objetiva (es decir, artefactos y entrevistas). 35.

(36) •. Se utiliza una escala diferente para caracterizar los componentes CMMI examinados [22].. De esta manera tendremos un punto de partida para la implementación de CMMI dentro de la empresa. Así mismo, esta evaluación puede ser apoyada por consultores externos, ya sea un Lead Appraiser o empresa experta, pero no es necesariamente obligatorio, de igual manera la empresa puede optar por realizar una evaluación Clase C, la cual podría dar un panorama un poco más amplio, pero sacrificando tiempo pues es más larga que la clase C. Existen distintas metodologías y guías para realizar una evaluación inicial, los siguientes procesos se plantean con base en una metodología realizada por dos investigadoras [23]. Figura 5: Metodología de diagnóstico [23]. La Figura 1 muestra un resumen de los procesos planteados en la metodología descrita anteriormente, así mismo, si se desea mayor detalle, se puede verificar la bibliografía, sin embargo, se da un pequeño resumen de la metodología: 4.2.1. Prerrequisitos y planeación del diagnóstico En esta etapa se prepara el terreno para la fase de ejecución a partir de doce actividades, como actividad inicial se tiene Contactar a un evaluador líder, no necesariamente tiene que ser un evaluador líder (lead appraiser) autorizado por el SEI, pero sí debe ser un experto en el método SCAMPI clase B. El patrocinador mostrará las necesidades y objetivos de la compañía mientras el Líder Evaluador, basado en su conocimiento, orientará al 36.

(37) patrocinador para obtener los insumos que se necesitan para dar arranque al inicio del diagnóstico. Después se encuentra la actividad Analizar Requerimientos del Diagnóstico, el patrocinador debe entender las necesidades del negocio y debe estar consciente del por qué es necesario el diagnóstico, él será quien defina los objetivos, alcance y los resultados esperados del proceso. Además, el líder evaluador deberá entender completamente lo definido por el patrocinador para así poder realizar el documento de planeación del diagnóstico. Acto seguido se debe Definir el Nivel de Madurez en el que se realizará el Diagnóstico. Para saber en qué nivel se debe basar el diagnóstico, se debe investigar si la organización ha tendido alguna experiencia con la evaluación en CMMI, si es el caso la organización podría sugerir al evaluador el alcance con el cual se hará la evaluación. Si la organización nunca se ha enfrentado a una evaluación o a un proceso de diagnóstico, será el Líder Evaluador, quien indicará el alcance de este. Definido el alcance para el cual se hará el diagnóstico se pueden determinar el número de miembros que serán necesarios para formar el Equipo Evaluador (basado en la siguiente tabla). El Líder Evaluador informará en un momento adecuado al Patrocinador los perfiles de las personas que deberán participar en el diagnóstico, con el fin de que se realice la selección adecuada. Una vez el Patrocinador encuentre los Miembros del Equipo Evaluador, los deberá proponer para que el Líder evaluador sea quien los apruebe. Definir los Proyectos que conformarán la muestra a diagnosticar. El Patrocinador debe seleccionar un conjunto de proyectos para conformar la muestra con la cual se llevará a cabo el diagnóstico. Para la Metodología de diagnóstico, el número de proyectos que conformarán la muestra representativa del diagnóstico serán 4, sin importar el nivel de madurez en el que se vaya a realizar el diagnóstico. Posteriormente se deben Definir las Fechas en las que se realizará el Diagnóstico. El patrocinador indicará en qué momento se puede comenzar con dicho proceso, con el fin de que los Miembros del Equipo Evaluador y las personas que serán entrevistadas cuenten con la disponibilidad de tiempo necesaria. Acto seguido se debe Elaborar el Cronograma del Diagnóstico, el cual debe ser elaborado por el Líder Evaluador y aprobado por el Patrocinador, y una vez se cuente con dicha aprobación, debe ser enviado a los Miembros del Equipo Evaluador. 37.

(38) Como tarea central se debe Elaborar el Documento de Planeación del Diagnóstico, documento que contendrá las bases para monitorear y controlar el proceso de diagnóstico. Este documento de planeación del diagnóstico debe ser elaborado por el Líder Evaluador y aprobado por el patrocinador, es un insumo indispensable para poder dar inicio al proceso de diagnóstico. Finalmente, una vez se tenga la aprobación, el documento debe ser enviado a los Miembros del Equipo Evaluador. Firmar Documento de Aprobación de Entradas del Diagnóstico, el Patrocinador debe responsabilizarse de que se incluya la información pertinente y necesaria en el cronograma y el documento de planeación. Por último, se debe hacer la aprobación de dichos insumos o entradas. Además, el Patrocinador debe firmar un documento donde conste la aceptación de dichas entradas del diagnóstico. Este documento de aprobación de entradas del diagnóstico también debe ser firmado por el Líder Evaluador. Finalmente, se deben ejecutar los siguientes pasos: •. Firmar Documento de Confirmación de Conocimiento de las Entradas del Diagnóstico (Miembros del Equipo Evaluador).. •. Firmar Acuerdo de Confidencialidad y de no Atribución. Terminada la fase de prerrequisitos y planeación del diagnóstico, se procede a ejecutar el mismo.. 4.2.2. Ejecución del Diagnóstico La etapa de “Ejecución del Diagnóstico” de la Metodología, consta de cinco fases, y a su vez, cada una de estas fases está conformada por un conjunto de subfases o actividades, como se expresa a continuación:. Figura 6: Etapas de ejecución de diagnóstico inicial [23]. 38.

(39) Preparación En la preparación se da inicio a la Ejecución del Diagnóstico; en ésta se establece de manera clara, antes de dar inicio al proceso de recolección de información y de evidencias, cuáles serán las reglas y procedimientos para seguir, para proceder con la evaluación. La primera actividad que se debe realizar en esta fase es la introducción inicial a la metodología para llevar a cabo el Proceso de Diagnóstico. Los miembros del equipo evaluador se reunirán con el líder para obtener una capacitación en la metodología de diagnóstico a utilizar. El líder deberá formar los Mini-Teams. Se debe hacer una revisión para verificar que todo lo que se definió en la planeación esté listo. Finalmente, algo imprescindible, es verificar que los miembros del equipo tengan todo claro. En la sección de preparación se debe realizar una presentación para las personas que se encargarán de suministrar información a los Mini-Teams. Esta exposición se debe basar en explicar el plan de recolección de información y de esta manera aumentar la probabilidad de que todas las personas a entrevistar tengan claridad en cuanto a sus responsabilidades y las actividades en las cuales jugarán un papel importante. Por último, antes de pasar a la fase de Recolección de Información, el documento de confirmación de conocimiento del plan de recolección de información debe haberse firmado por parte de todas las personas a entrevistar. Recolección de la información Es momento entonces de realizar las entrevistas, dichas entrevistas son realizadas por el grupo evaluador, con una serie de cuestionarios y entrevistas complementarias. Cuando el grupo evaluador haya terminado de hacer la entrevista, cada Mini-Team se encargará del análisis de la información relacionada con el subconjunto de áreas de proceso que le corresponda. Los Mini-Teams han recolectado en este momento evidencias relacionadas con las áreas de proceso a las que fueron asignados, dichas evidencias resultaron de las entrevistas iniciales y complementarias, para los casos en que fueron necesarias. Análisis de información En esta fase se analiza la información recolectada en la fase anterior, con el fin de poder determinar las debilidades y fortalezas de la Organización de Software bajo estudio. Como primera medida, la información se recolectará de manera independiente, cada Mini-Team 39.

(40) será el encargado de realizar el análisis de la información que haya recolectado con respecto a las áreas de proceso a las cuales hayan sido asignadas. Una vez que cada Mini-Team haya realizado dicho análisis, se debe realizar una integración de esa información que fue analizada de manera independiente. Lo que significa que se debe realizar una reunión del Equipo Evaluador (Líder y Miembros del Equipo Evaluador), con el fin de que cada Mini-Team de a conocer a los demás, la información que recolectó, y el análisis que efectuó sobre dicha información. Después de que el Equipo Evaluador tenga conocimiento del total de información recolectada, se debe iniciar un proceso de análisis de la información integrada, y en caso de que surjan dudas, se debe proceder a citar a las personas indicadas para resolverlas. Lo que se hace entonces es que se efectúan una serie de entrevistas finales, que serán dirigidas por el Equipo Evaluador. Con todo lo anterior, el Equipo Evaluador podrá efectuar la evaluación, es decir, iniciar el proceso de toma de decisiones, para determinar las debilidades y fortalezas de la Organización para la cual se está efectuando el diagnóstico. El proceso de evaluación debe ser realizado con la participación de todos y cada uno de los Integrantes del Equipo Evaluador, a través de la toma de decisiones en consenso. Éste se lleva a cabo por áreas de proceso (evaluando todas las prácticas y metas que correspondan a cada área de proceso). Una vez se evalúen todas las áreas de proceso, se deben identificar las debilidades y las fortalezas de la Organización, teniendo en cuenta el nivel de madurez en el que se esté realizando el diagnóstico con respecto al modelo de referencia CMMI. Para finalizar con esta fase, el Líder Evaluador debe haber elaborado el informe de resultados del diagnóstico efectuado a la Organización de Software bajo estudio, el cual debe contener las debilidades y fortalezas de dicha organización, y las recomendaciones, sugerencias y pasos a seguir por la misma. [23] Presentación de resultados Esta es una de las fases finales de la Metodología de Diagnóstico, la cual consiste en divulgar a las personas autorizadas, los resultados obtenidos y entregar el informe de los resultados del diagnóstico al Patrocinador Cierre de la evaluación inicial 40.

(41) La primera actividad de esta fase corresponde a la elaboración del documento de lecciones aprendidas, el cual está a cargo del Líder Evaluador. Este documento debe incluir tanto los aspectos negativos como los aspectos positivos que formaron parte del proceso de diagnóstico, y debe ser entregado al Patrocinador (el documento de lecciones aprendidas debe respetar todo lo que está contemplado en el Acuerdo de Confidencialidad y no Atribución). Se eliminan todas las notas con las que fueron documentadas las evidencias de la Organización, que se hayan recolectado durante las entrevistas, ya que ésta es información confidencial, y además pone en riesgo el anonimato de las personas que suministraron información. Luego, se realiza el acta de cierre, con el fin de que quede constancia de que el proceso de diagnóstico se llevó a cabo, y la Organización de Software que fue examinada quedó satisfecha con las actividades desarrolladas a lo largo de dicho proceso. Por último, se realiza la reunión de cierre para dar por terminado el proceso de diagnóstico. Concluido la etapa del diagnóstico, la organización debe tener bases firmes para establecer un foco, teniendo clara la capacidad de los procesos a la luz del modelo y qué áreas de proceso están cubiertas por el estado actual; como resultado, se debe saber hacia qué nivel dirigirse y por ende cuáles serán las áreas de proceso en las que se deberán enfocar los esfuerzos de mejora.. 4.3. IMPLEMENTACIÓN DE CMMI Para la implementación de CMMI, se usará el modelo IDEAL, el cual fue presentado por el mismo SEI como un modelo de ciclo de vida para la mejora de procesos basado en CMMI. Está compuesto de cinco fases que permiten administrar el programa de mejora y establecer las bases para la estrategia de mejora a largo plazo. Las fases que componen el modelo son: 1. Initiating (Iniciar) 2. Diagnosing (Diagnosticar) 3. Establishing (Establecer) 4. Acting (Ejecutar) 5. Learning (Aprender) 41.

(42) 4.3.1. Iniciar Las actividades que componen esta fase son críticas para el éxito de todo el programa ya que aquí se establecen las bases del trabajo a realizar. Comienza con un reconocimiento de las necesidades de cambio en la organización. Mientras más evidentes sean estas necesidades mayor aceptación y posibilidad de éxito tendrá el cambio. Considerando las razones para iniciar el cambio es necesario establecer las metas y objetivos del trabajo a realizar, evaluar la forma en que se afectará el trabajo y los beneficios que se esperan obtener. Paralelo a esto es necesario contar con un apoyo efectivo de la dirección desde que se inicia el programa. Para ello es necesario que la dirección brinde una atención directa y tenga compromiso con el programa. Finalmente es necesario establecer la estructura organizativa que apoyará el programa de mejora y documentar las responsabilidades y expectativas de cada grupo. Típicamente se crea el Management steering group (MSG) y el Software engineering process group (SEPG). 4.3.2. Diagnosticar El objetivo de esta fase es obtener un entendimiento completo del trabajo a realizar para lo cual es necesario caracterizar el estado actual de la organización y el estado futuro. Por lo general esta evaluación se realiza con base en algún modelo de referencia como puede ser CMM. En este caso se puede realizar un SCAMPI en alguna de las clases definidas, si es la primera vez que se hace se recomienda un SCAMPI clase C o B. Como resultado de la evaluación se proponen recomendaciones que sirven para definir las actividades siguientes del programa y que influyen en las decisiones que debe tomar la gerencia. 4.3.3. Establecer Durante la fase se elabora un plan detallado con acciones específicas, entregables y responsabilidades para el programa de mejora basado en los resultados del diagnóstico y en los objetivos que se quieren alcanzar. Para elaborar el plan se parte de definir las prioridades para el esfuerzo de mejora, para ello se consideran los recursos, dependencias, factores externos y necesidades de la organización. Posteriormente se identifica el enfoque a seguir considerando las prioridades y los resultados del diagnóstico. Adicionalmente se. 42.

(43) definen las métricas que permitirán medir el progreso alcanzado y se comienzan a definir y capacitar a los grupos técnicos de trabajo que desarrollarán los procesos. 4.3.4. Ejecutar Es la fase que más tiempo y recursos consume ya que es cuando se implementan las acciones que han sido planeadas. La fase inicia con la definición de la solución que cubre los objetivos de la organización. La solución comprende: herramientas, procesos, habilidades, asesorías e información y generalmente es desarrollada por los grupos técnicos de trabajo que se establecieron. La solución propuesta es probada en proyectos pilotos y posteriormente refinada para reflejar la experiencia, conocimiento y lecciones aprendidas en las pruebas. El proceso se itera hasta obtener una solución satisfactoria que funcione, sin esperar a que sea perfecta. Finalmente la solución obtenida se comienza a implantar en la organización. 4.3.5. Aprender Esta fase cierra el ciclo de mejora y su objetivo es garantizar que el próximo ciclo sea más efectivo. Durante la misma se revisa toda la información recolectada en los pasos anteriores y se evalúan los logros y objetivos alcanzados para lograr implementar el cambio de manera más efectiva y eficiente en el futuro. Las lecciones aprendidas deben quedar documentadas. Adicionalmente deben reevaluarse las metas del negocio y verificar su cumplimiento, así como proponer mejoras para las siguientes etapas del proceso.. 4.4. DEFINICIÓN DE MODELO DE MEJORAMIENTO Ya definido, que usaremos IDEAL, como modelo de mejoramiento, se tendrá entonces que realizar algunos ajustes a este modelo para la implementación de CMMI. Siguiendo los 5 componentes del modelo IDEAL tenemos que con la caracterización de la empresa, nos hemos adelantado a la primera etapa: Inicio, aquí ya hemnos identificado la empresa, los objetivos y hemos asegurado el resplado de la empresa para la implementación del mismo. Por el lado de Diagnóstico, ya se abarcó previamente con la evaluación inicial, en este paso encontramos ya el estado actual a la empresa y sabemos que debemos llevar a cabo para 43.

(44) la implementación del mismo, por lo que nos faltaría abarcar las 3 etapas restantes. Dado que además de integrar CMMI, deseamos implementar una metodología de desarrollo ágil (scrumban), definirremos el modelo de mejoramiento también teniendo en cuenta este componente. El propósito general de definir un modelo de mejoramiento es generar un plan de acción que incluya la planificación detallada de las acciones a realizar a fin de llevar a la organización hacia el nivel deseado. Para esto hay que cubrir las siguientes tareas [24]: 4.4.1. Establecer prioridades La finalidad de esta tarea se centra en definir las prioridades en términos de áreas de proceso y mejores prácticas a integrar, derivadas de las necesidades de la organización. Al establecer las prioridades se deben tener en cuenta aspectos como los recursos para el proyecto, la dependencia de algunas actividades con otras, y las prioridades organizacionales. Es común que la empresa tenga algunas prioridades en mente. Sin embargo, es indispensable evaluar a conciencia las necesidades que se hicieron evidentes en la evaluación inicial (Diagnóstico), tanto en términos de mejoras puntuales en algunos procesos, como en términos de áreas de proceso que requerirían ser implantadas o mejoradas para alcanzar el nivel objetivo. Una vez se evalúan, se deben reorganizar las prioridades acordes con estas nuevas necesidades; no todas las que fueron identificadas serán prioritarias, y puede que algunas de las necesidades prioritarias no se encuentren entre las necesidades más importantes, como lo es el caso de una prioridad que se derive de un costo de oportunidad o de una necesidad temporal de la empresa. Por ejemplo, una necesidad prioritaria para cumplir un compromiso comercial: Suponga una empresa enfocada en alcanzar nivel 2 que debe tener implantada el área de proceso OT (“Organizational Training” de nivel 3 de madurez) en una fecha límite para una licitación. Entonces implementar dicha área de proceso será prioritario, pero menos importante que las áreas de proceso de nivel 2 puesto que de estas dependen el objetivo primordial. Para establecer adecuadamente las prioridades, se deben tener en cuenta las necesidades con las que se justificaron los objetivos del proyecto y las recomendaciones que entregó el diagnóstico, para luego priorizar las acciones a realizar. Para esta priorización, es útil considerar los siguientes aspectos:. 44.