UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS FACULTAD DE INGENIERIA PROGRAMA ACADÉMICO DE INGENIERÍA DE SISTEMAS
"Evaluación del cumplimiento de prácticas RD, TS, PI, VER y VAL del modelo CMMI, aplicado al proceso actual de Desarrollo de Software de la empresa Sentinel Perú S.A." TRABAJO FINAL
AUTOR(ES) Garcia Moreano, Alejandro Francisco (u201911064) Chuán Méndez, Eder Alonso (u201500424) Cruz Carpio, Nicolas Benjamín (u201912120) Ochoa La Cruz, Elmer Alexander (u201912866) Alcarraz Neya, Jean Piere (u201725907)
PROFESOR Maco Victoria, José Brando
Lima, 19 de junio de 2020
ÍNDICE
3 TABLE OF CONTENTS 3
INTRODUCCIÓN........................................................................................................1
4
OBJETIVO DEL ESTUDIO.......................................................................................2 A.
DESCRIPCIÓN DE LA EMPRESA.................................................................................2
B.
MISIÓN DE LA EMPRESA...........................................................................................2
C.
VISIÓN DE LA EMPRESA............................................................................................3
D.
ORGANIGRAMA DE LA EMPRESA..............................................................................3
E.
OBJETIVOS ESTRATÉGICOS DE LA EMPRESA...........................................................3
5
ALCANCE DE LA EVALUACIÓN...........................................................................4
6
FACTIBILIDAD DEL CAMBIO................................................................................5
7
ANÁLISIS ORGANIZACIÓNAL..............................................................................6
8
EVALUACIÓN DE LA SITUACIÓN ACTUAL.......................................................9 A.
PROCESOS ACTUALES DE LA EMPRESA....................................................................9
B.
INDICADORES DE MEJORA......................................................................................16
C.
DESCRIPCIÓN DE LAS FUENTES DE INFORMACIÓN................................................18
D.
EVALUACIÓN DEL CUMPLIMIENTO DE LAS PRÁCTICAS ESPECÍFICAS..................19
E.
PRESENTACIÓN DE RESULTADOS............................................................................30
F.
PLAN DE IMPLEMENTACIÓN DE MEJORAS..............................................................41
G.
CONCLUSIONES........................................................................................................43
H.
REFERENCIAS BIBLIOGRÁFICAS.............................................................................44
I.
ANEXOS....................................................................................................................46
1
ÍNDICE DE TABLAS [Sección obligatoria que se debe realizar cuando el documento esté terminado. Aquí se visualiza la estructura de tablas incluidas en el trabajo.]
2
ÍNDICE DE FIGURAS
Figura 1. Logo Sentinel Perú S.A..........................................................................................2 Figura 2. Organigrama a nivel de direcciones de Sentinel Perú S.A....................................3 Figura 3. Mapa Estratégico de Sentinel Perú S.A.................................................................4 Figura 4. Diagrama de Ishikawa de Sentinel Perú S.A.........................................................6 Figura 5. Diagrama de Ishikawa de Sentinel Perú S.A.........................................................7 Figura 6. Diagrama de Ishikawa de Sentinel Perú S.A.........................................................7 Figura 7. Diagrama de Ishikawa de Sentinel Perú S.A.........................................................8 Figura 8. Flujograma del subproceso Gestión de Requisitos................................................9 Figura 9. Flujograma del subproceso Gestión de Desarrollo.............................................11 Figura 10. Flujograma del subproceso Gestión de Despliegue..........................................12 Figura 11. Flujograma del subproceso Gestión de QA.......................................................14 Figura 12. Flujograma del subproceso Gestión de Ratificación en Pre-Producción..........15 Figura 13. Flujograma del subproceso Gestión de Corrección de Issues...........................16 Figura 14. Resumen total de la evaluación en PA por SG...................................................32 Figura 15. Participación de prácticas evaluadas por caracterización de evaluación SCAMPI A............................................................................................................................36 Figura 16. Resultados de evaluación por PA.......................................................................41
3
3
INTRODUCCIÓN
Hoy en día llevar a cabo una buena gestión de proyectos es una tendencia global, porque maximiza los resultados de los entregables y garantiza el crecimiento de las organizaciones tomando como principal impulsor de estas prácticas el área de Desarrollo de Software dentro de cada empresa donde está involucrada. Sin embargo, a medida que las organizaciones crecen, los recursos utilizados para los procesos internos de éstas tienden a ser insuficientes, porque se necesitan de otras herramientas para abastecer la administración dentro del área de Desarrollo y, en general, de los departamentos de TI, como por ejemplo una guía requerida para el uso de buenas prácticas. Ante esta premisa, se debe tomar como referencia a CMMI, el cual es un modelo de madurez que contiene las mejores prácticas para apoyar y mejorar los procesos de negocio. Dicho modelo ayuda a que el proceso de Desarrollo de Software, su mantenimiento y su operación dentro de las empresas sea más eficientes. Por lo anterior, una de las empresas en el rubro de servicios de información especializada en operaciones de gestión de riesgos es Sentinel Perú S.A., quien apuesta por la innovación tecnológica, además pone a disposición de las empresas la información de riesgos crediticios a nivel nacional y dispone de las certificaciones ISO 9001 e ISO 27001 correspondientes al cumplimiento de Estándares de Calidad Internacionales y de Seguridad de Información, respectivamente. En el presente proyecto, se evaluará el cumplimiento de las prácticas RD, TS, PI, VER y VAL del modelo CMMI, aplicados al proceso Desarrollo de Software. Con lo anterior, se identificará el nivel de madurez actual del proceso y se definirá el plan de mejoras a implementar. Finalmente, cabe mencionar que, con el desarrollo de la mejora se desea llegar a los objetivos trazados, con el fin de que todos los trabajadores compartan la visión de hacia dónde se dirige la empresa en los próximos años y se tenga como base para el cumplimiento del Plan Estratégico 2021.
1
4
OBJETIVO DEL ESTUDIO
a.
Descripción de la empresa
Sentinel Perú S.A., empresa del rubro de Central de Riesgos Crediticios con más de 9 años en el mercado, ubicada en Perú Lima, país de Sudamérica con aproximadamente 60 entidades financieras reguladas por la Superintendencia de Banca, Seguros y AFP (SBS), la cual se encarga de consolidar la información de deudas a través del Reporte Crediticio Consolidado (RCC), para luego ser proveída a Sentinel. La empresa cuenta con más de 100 colaboradores brindando servicios de reportes y alertas crediticias (desde el año 2010) a través de su página web http://www.sentinelperu.com, y se diferencia de su competencia por presentar la información crediticia de manera práctica y sencilla de entender, brindando además alertas sobre cambios en el historial crediticio del cliente. Sentinel también brinda servicios de información financiera a medida a empresas según los requerimientos que soliciten. Además, la empresa muestra garantía de la continuidad de su información al tener como aliado a la reconocida empresa informática IBM, la cual brinda servicios de recepción, procesamiento y almacenamiento de la información para el desarrollo de sus actividades. La empresa dispone de las certificaciones ISO 9001 e ISO 27001 correspondientes al cumplimiento de Estándares de Calidad Internacionales y de Seguridad de Información, respectivamente.
Figura 1. Logo Sentinel Perú S.A. Fuente: Portal Sentinel Perú S.A. b.
Misión de la empresa
"Brindar herramientas estratégicas de información y gestión a empresas y personas, que permitan anticipar riesgos y oportunidades, facilitando la toma de decisiones acertadas, promoviendo la transparencia de la información del mercado, fomentando la cultura de cumplimiento y que finalmente contribuyan con el desarrollo de la competitividad del país."
2
c.
Visión de la empresa
"Convertirnos en la empresa más importante del Perú en proveer información proactiva, inteligente y anticipada sobre riesgos y oportunidades de las empresas y personas."
d.
Organigrama de la empresa
Figura 2. Organigrama a nivel de direcciones de Sentinel Perú S.A. Fuente: Intranet Sentinel Perú S.A. e.
Objetivos estratégicos de la empresa
Incrementar la rentabilidad de los productos. Mejorar el entendimiento de los reportes. Fortalecer la imagen de Sentinel Perú S.A. como una empresa innovadora. Utilizar nuevas tecnologías para evitar demoras en el tiempo de respuesta de
aplicaciones. Garantizar la continuidad del servicio. Buscar alianzas estratégicas en el extranjero para nuevos campos de acción. Fomentar la cultura de innovación en todo el personal. Promover horario de innovación para la generación de nuevas ideas de productos.
3
Figura 3. Mapa Estratégico de Sentinel Perú S.A. Recuperado de: “una adaptación propia”
5
ALCANCE DE LA EVALUACIÓN
El alcance de evaluación del presente trabajo son proyectos de desarrollo de software de información financiera solicitados por los clientes del sector financiero (Bancos, Financieras, Cajas Rurales), telecomunicaciones y retail, principalmente. Entre los principales productos se encuentran Mapas Interactivos, Tableros Analíticos, Evaluaciones Crediticias, Procesos Batch. Por otro lado, el proceso de Desarrollo de Software de la empresa Sentinel Perú S.A. se desarrolla bajo la metodología tradicional y se usa un ciclo de vida de Desarrollo en cascada. El proceso está integrado por los subprocesos Gestión de Requisitos, Gestión de Desarrollo, Gestión de Despliegue, Gestión de QA, Gestión de Ratificación en Pre-Producción, Gestión de Corrección de Issues. Con el modelo CMMI se abordarán las áreas de proceso de Desarrollo de Requisitos (RD), Solución Técnica (TS), Integración de Producto (PI), Verificación (VER) y Validación (VAL).
4
6
FACTIBILIDAD DEL CAMBIO Rol o función dentro de la Organización
Analista Comercial
Analista Implementaciones
Grado de Influencia Alto
de
Medio
Jefe de Proyectos
Alto
Jefe de Desarrollo
Alto
Jefe de Arquitectura
Alto
Analista de Pricing
Medio
Analista de BI
Alto
Analista de Desarrollo
Alto
Tipo de actitud ate el cambio Líderes en innovación: Entusiasta sobre nuevas formas de trabajo. No muestra resistencia. Mayoría temprana: No toma riesgos y solo acepta aquello que ha sido probado. Resistencia abierta (requiere evidencias) Mayoría temprana: Prefiere antes conocer información sobre el valor que brinda el cambio, así como experiencia de otros. Resistencia abierta (requiere evidencias) Primeros adoptadores: Tiene carisma para influenciar en la organización. No muestra resistencia Líderes en innovación: Quiere ser uno de los primeros en lograr que las cosas funcionen. No muestra resistencia. Mayoría temprana: No toma riesgos y solo acepta aquello que ha sido probado. Resistencia abierta (requiere evidencias). Primeros adoptadores: Tiene temperamento para llevar esa intuición a un proyecto altamente visible y riesgoso. Tiene carisma para influenciar en la organización. No muestra resistencia. Primeros adoptadores: Tiene carisma para
5
Analista de Operaciones
Medio
Analista de QA
Medio
Asistente de QA
Bajo
7
influencia en la organización. No muestra resistencia. Mayoría tardía: Está en contra de los cambios. Resistencia encubierta (requiere evidencias). Mayoría temprana: Pragmático. Resistencia abierta (requiere evidencias). Mayoría temprana: No toma riesgos y solo acepta aquello que ha sido probado. Resistencia abierta (requiere evidencias).
ANÁLISIS ORGANIZACIÓNAL
Situación problemática Cuando el Área de Operaciones se dispone a desplegar el producto y se ve obstaculizado debido que el sistema no responde, por falta de componentes o por versiones antiguas no compatibles. Cuando se entrega funcionalidades para ser probadas por el Área de QA y dicho equipo encuentra demasiados errores en el proceso core. Cuando una persona del Área de Desarrollo no continúa trabajando para Sentinel, su retiro genera todo un replanteamiento de procesos de desarrollo Cuando algún participante del Área de Desarrollo no asiste al trabajo, se genera retraso y algunos procesos se ven estancados hasta que la persona ausente se reincorpore
Problema a resolver
Herramienta
Demora en los tiempos de despliegue de los artefactos de Diagrama de software. En la mayoría de los Ishikawa, ver casos el Área de Desarrollo no Figura 4 envía los componentes completos o se tiene una versión desfasada. Existe mucha devolución de funcionalidad por parte del Área Diagrama de de QA hacia el Área de Desarrollo. Ishikawa, ver En algunos casos se ha devuelto el Figura 5 desarrollo completo. Los procesos de desarrollo están Diagrama de asociado al recurso humano y no a Ishikawa, ver procesos de la empresa. Figura 7 El conocimiento y uso de herramientas se encuentra Diagrama de asociado a un recurso humano y Ishikawa, ver no al equipo, dicho de otro modo, Figura 7 el conocimiento no se distribuye.
6
Cuando el Área de Desarrollo se encuentra en etapa de construcción del software y se encuentra cerca de la fecha de entrega, se omiten procesos como uso de estándares, pruebas unitarias, etc., debido que prima la entrega.
No se llega a cumplir todos los procesos, en algunos casos Diagrama de algunos procesos internos de Ishikawa, ver desarrollo son omitidos por temas Figura 9 de tiempo.
Figura 4. Diagrama de Ishikawa de Sentinel Perú S.A. Recuperado de: “una adaptación propia”
Figura 5. Diagrama de Ishikawa de Sentinel Perú S.A. Recuperado de: “una adaptación propia”
7
Figura 6. Diagrama de Ishikawa de Sentinel Perú S.A. Recuperado de: “una adaptación propia”
Figura 7. Diagrama de Ishikawa de Sentinel Perú S.A. Recuperado de: “una adaptación propia”
8
8 a.
EVALUACIÓN DE LA SITUACIÓN ACTUAL Procesos actuales de la empresa
A continuación, se muestran los flujogramas de los subprocesos del proceso Desarrollo de Software de la empresa Sentinel Perú S.A.
Subproceso Gestión de Requisitos
Figura 8. Flujograma del subproceso Gestión de Requisitos Recuperado de: “una adaptación propia” Documentación de procesos graficados en el punto anterior: Id
Título de Actividad
Descripción de la Actividad
Entregable Entrada
Entregable Salida
Rol
1
Enviar Necesidad Negocio
-
-
Cliente
2
Definir
El Cliente envía la necesidad del negocio a la empresa. Se define la solicitud
-
Solicitud
de
Requerimiento
de
Analista
9
con el Cliente Evaluar variables del Requerimiento para definir el monto a cobrar por su implementación Elaborar documento funcional del Requerimiento
del requerimiento. Se analiza el requerimiento para evaluar monto a cobrar. Se elabora documento funcional de requerimiento.
5
Definir áreas de TI involucradas en la implementación del Requerimiento
Se identifica y se detecta las áreas involucradas en el requerimiento.
Formato de solicitud de Requerimiento TI
6
Estimar esfuerzo por la implementación del Requerimiento
7
Consolidar estimación de esfuerzo de cada área involucrada Definir monto a cobrar por la implementación del Requerimiento
El área correspondiente evalúa el esfuerzo que utilizará. Junta todos los informes de cada área involucrada. Se define monto a cobrar con la información de los involucrados. Se elabora orden de compra.
3
4
8
Formato de solicitud de Requerimiento TI -
Analista de Implementacione s
Formato de solicitud de Requerimiento TI Cronograma de Requerimiento
Cronograma de Requerimiento
Jefes de áreas involucradas
-
Jefe de Proyectos
-
-
Analista Pricing
-
Analista Comercial
-
de
Jefe de Proyectos
de
Elaborar Compra
10
Enviar Orden de Compra y tiempo estimado de la implementación del Requerimiento Evaluar Orden de Compra y tiempo estimado de implementación Recepcionar Orden de Compra aceptada
Se envía orden de compra a Cliente.
Orden de Compra de Requerimiento
Orden de Compra de Requerimiento Orden de Compra de Requerimiento
El cliente evalúa orden de compra y toma decisiones.
Orden de Compra de Requerimiento
Orden de Compra de Requerimiento
Cliente
Se recepciona Orden de compra de cliente.
-
Analista Comercial
Enviar Solicitud de Requerimiento Gestionar cronograma con Área Técnica
Se envía la solicitud del requerimiento Coordina con el área técnica
Orden de Compra de Requerimiento Solicitud de Requerimiento -
-
Gestionar cronograma con Áreas Involucradas Definir solución tecnológica del Requerimiento Formular propuesta de arquitectura de base de datos Evaluar propuesta de arquitectura de base de datos Definir arquitectura de base de datos
Coordina con las áreas involucradas Se define la solución que se implementará.
-
Se realiza modelo de Base de Datos
-
Cronograma de Requerimiento Documento de Análisis y Diseño -
Analista Comercial Analista de Implementacione s Jefe de Proyectos
Se evalúa propuesta de Base de Datos
-
Se define arquitectura final de Base de Datos
-
12 13 14 15 16 17 18 19
de
Comercial Analista Pricing
9
11
Orden
Requerimiento -
Solicitud de Requerimiento
-
Cronograma de Requerimiento
Analista Comercial
Jefe de Desarrollo Jefe Arquitectura
de
-
Jefe Arquitectura
de
Documento de Análisis y Diseño
Jefe Arquitectura
de
10
Subproceso Gestión de Desarrollo
Figura 9. Flujograma del subproceso Gestión de Desarrollo Recuperado de: “una adaptación propia” Documentación de procesos graficados en el punto anterior: Id
Título de Actividad
Descripción de la Actividad
Entregable Entrada
Entregable Salida
Rol
1
Analizar requerimiento desde alcance BI
Se analiza requerimiento parte de BI.
-
Analista de BI
2
Definir solución BI
-
Analista de BI
3
Desarrollar solución BI
-
-
Analista de BI
4
Analizar requerimiento desde alcance Desarrollo
Se define solución a implementar. Se desarrolla solución definida anteriormente. El equipo de Desarrollo analiza el requerimiento.
Formato de solicitud de Requerimiento TI -
-
Analista Desarrollo
de
5
Definir Desarrollo
Formato de solicitud de Requerimiento TI -
Analista Desarrollo
de
6
Ejecutar desarrollo requerimiento
de
Analista Desarrollo
de
7
Ejecutar desarrollo seguridad
de
-
Analista Desarrollo
de
8
Implementar Componentes de Despliegue Realizar pruebas unitarias
Componentes de Despliegue
Analista Desarrollo
de
-
Analista Desarrollo
de
Documento Manual de Usuario Documento de pase a QA y Producción -
Analista Desarrollo
de
Analista Desarrollo
de
Analista
de
solución
el por
Se define solución a implementar. Se desarrolla la solución definida anteriormente. Se desarrolla la solución de seguridad.
Documento Análisis Diseño Documento Análisis Diseño -
de y
Documento Análisis Diseño -
de y
de y
10
Elaborar Documento Manual de Usuario
Se crean componentes de despliegue (jar, properties, etc.) Se realizan pruebas unitarias después de desarrollo. Se elabora el Manual de Usuario.
11
Elaborar Documento de pase a QA y Producción
Se elabora el documento de Pase.
-
12
Realizar
Guardar componentes
Componentes de
9
commit
de
Documento Análisis Diseño -
de y
11
13
Componentes de Despliegue Enviar documentación de pase para despliegue
en repositorio. Se documentación despliegue.
Despliegue envía para
Documento de pase a QA y Producción
Desarrollo -
Analista Desarrollo
de
Gestión de Despliegue
Figura 10. Flujograma del subproceso Gestión de Despliegue Recuperado de: “una adaptación propia” Documentación de procesos graficados en el punto anterior: Id
Título de Actividad
Descripción de la Actividad
Entregable Entrada
Entregable Salida
Rol
1
Recibir de pase
documentación
Recibe documentación del proceso anterior.
-
Analista de Operaciones
2
Validar documentación de pase
Valida documentación.
-
Analista de Operaciones
3
Desplegar aplicación
Se aplicación.
-
Analista de Operaciones
4
Notificar responsable
Documento de Pase de QA y Producción Documento de Pase de QA y Producción Documento de Pase de QA y Producción -
-
Analista de Operaciones
5
-
-
6
Validar despliegue aplicación Validar ambiente
-
7
Realizar rollback
Documento de Pase de QA y Producción -
Analista de Operaciones Analista de Operaciones
-
Analista de Operaciones
8
Notificar conformidad de despliegue
-
-
Analista de Operaciones
9
Ejecutar Testing
-
Sistema Penetration Test
10
Generar Informe Vulnerabilidades
Documento de Pase de QA y Producción -
Informe de Vulnerabilidades
Sistema Penetration Test
al
área de
Penetration de
despliega
Se notifica al área responsable si algo falla. Se valida el despliegue Se valida ambiente en que se realizó el despliegue. Se realiza rollback del despliegue si es que algo falla. Se notifica conformidad de despliegue. Se ejecuta herramienta de validación Se genera informe de vulnerabilidades.
12
11
Validar Informe Vulnerabilidades
de
Se valida informe de vulnerabilidades.
Informe de Vulnerabilidades
-
Analista de Operaciones
Gestión de QA
Figura 11. Flujograma del subproceso Gestión de QA Recuperado de: “una adaptación propia” Documentación de procesos graficados en el punto anterior: Id
Título de Actividad
Descripción de la Actividad
Entregable Entrada
Entregable Salida
Rol
1
Analizar requerimiento desde alcance QA
Se analiza requerimiento por parte de QA.
-
Analista QA
2
Elaborar Plan de Pruebas
Plan de Pruebas
Analista QA
3
Ejecutar Validación de código
-
-
Sistema Veracode
4
Generar Informe de Validación de código
Se elabora el plan de pruebas. Se ejecuta la validación de código en busca de vulnerabilidades. Se genera informe de validación de código.
Formato de solicitud de Requerimiento TI -
-
5
Validar Informe de Validación de código
Se valida informe creado del sistema.
Informe Validación código -
6 7
Ejecutar Plan de Pruebas Elaborar Informe de Plan de Pruebas Enviar Informe de Plan de Pruebas
Se ejecutan pruebas. Se elabora informe de plan de pruebas. Se envía informe de plan de pruebas.
8
Informe de Validación de código Plan de Pruebas Informe de Plan de Pruebas
de de
Informe de Plan de Pruebas -
Sistema Veracode Asistente QA Asistente QA Asistente QA Analista QA
13
Gestión de Ratificación en Pre-Producción
Figura 12. Flujograma del subproceso Gestión de Ratificación en Pre-Producción Recuperado de: “una adaptación propia” Documentación de procesos graficados en el punto anterior: Id
Título de Actividad
Descripción de la Actividad
Entregable Entrada
1
Solicitar revisión y conformidad del Cliente
Se solicita revisión de producto a Cliente. Se envía Documento Manual de Usuario. Se ejecuta pruebas funcionales en el aplicativo preproductivo.
Documento Manual Usuario.
de
Documento Manual Usuario
de
2
Ejecutar pruebas aplicativo
3
Notificar conformidad
4
Notificar rechazo implementación Requerimiento Elaborar Acta Conformidad
5 6
en
de de de
Enviar constancia de Acta
Se notifica conformidad al Analista de Implementaciones. Se notifica rechazo al Analista de Implementaciones. Se elabora Acta de Conformidad. Se envía constancia
Entregable Salida
Rol
-
Analista de Implementacione s
-
Cliente
Solicitud de Requerimiento -
-
Cliente
-
-
Cliente
-
Acta de Conformidad
Analista de Implementacione s Analista de
Acta
de
-
14
de Conformidad Cliente
al
Acta de Conformidad al Cliente.
Conformidad
Implementacione s
Gestión de Corrección de Issues
Figura 13. Flujograma del subproceso Gestión de Corrección de Issues Recuperado de: “una adaptación propia” Documentación de procesos graficados en el punto anterior: Id
Título de Actividad
Descripción de la Actividad
Entregable Entrada
1
Verificar Informe de Plan de Pruebas
Se verifica informe de pruebas.
2
Definir solución de Issues de desarrollo
3
Definir solución de Issues de seguridad
4
Ejecutar desarrollo de Issues
Se define solución a implementar para los issues. Se define solución sobre la seguridad a implementar para los issues. Se ejecuta desarrollo de la issue.
Informe Plan Pruebas -
5
Implementar Componentes Despliegue
de
6
Realizar unitarias
7
Actualizar Documento Manual de Usuario Actualizar Documento de pase a QA y Producción Realizar commit de Componentes de Despliegue Enviar documentación de pase para despliegue
8 9 1 0
pruebas
Se generan componentes para despliegue (jar, properties, etc). Se realizan pruebas unitarias del desarrollo. Se actualiza documento de usuario.
Entregable Salida
Rol
-
Analista Desarrollo
de
Documento de Análisis y Diseño Documento de Análisis y Diseño
Analista Desarrollo
de
Analista Desarrollo
de
Documento de Análisis y Diseño -
-
Analista Desarrollo
de
Componentes de Despliegue
Analista Desarrollo
de
Documento de Análisis y Diseño -
-
Analista Desarrollo
de
Documento Manual de Usuario Documento de pase a QA y Producción -
Analista Desarrollo
de
Analista Desarrollo
de
Analista Desarrollo
de
-
Analista Desarrollo
de
de de
-
Se actualiza documento de pase.
-
Se guarda componentes en repositorio. Se envía documentación de pase para despliegue.
Componentes de Despliegue Documento de pase a QA y Producción
15
b.
Indicadores de mejora
Área de Proceso Desarrollo de Requisitos Nombre Descripción
Fórmula Resultado Esperado
Objetivo
Plan de Medición
Tasa de requisitos mal definidos en los proyectos El indicador mide el porcentaje de requisitos mal definidos respecto del total de requisitos. El Analista de Desarrollo reporta al Jefe de Desarrollo los requerimientos poco claros y ambiguos definidos en la Solicitud de Requerimiento. Este último registra la cantidad de requisitos mal definidos en los proyectos. (Cantidad de requisitos mal definidos) / (Cantidad total de requisitos) * 100 [0 – 5 %> Bueno [5 – 10 %> Regular [10 – 100 %] Malo El resultado esperado del indicador es tener como máximo 5% de requisitos mal definidos, del total. Reducir el porcentaje de errores en la captura de requisitos. Responsable de toma de Jefe de Desarrollo medición Frecuencia a realizar la Por proyecto medición Personas involucradas Analista de Desarrollo, Analista Comercial.
Área de Proceso Solución Técnica Nombre Descripción
Fórmular Resultado Esperado
Objetivo
Tasa de Pruebas Unitarias erradas El indicador mide el porcentaje de Pruebas Unitarias erradas respecto del total de Pruebas Unitarias realizadas. El Área de Desarrollo realiza las Pruebas Unitarias para validar la implementación realizada antes de elaborar el Documento de pase a QA y Producción. El Analista de Desarrollo identifica las Pruebas Unitarias erradas al momento de realizarlas en Genexus. (Cantidad de P.U. erradas / Cantidad de P.U.) * 100 [0 – 2 %> Bueno [2 – 10 %> Regular [10 – 100 %] Malo El resultado esperado del indicador es tener como máximo 2% de Pruebas Unitarias erradas, del total. Reducir el porcentaje de Pruebas Unitarias erradas para realizar el pase a QA. Responsable de toma de Jefe de Desarrollo 16
medición Frecuencia a realizar la Por pase al área de QA. medición Personas involucradas Analista de Desarrollo
Plan de Medición
Área de Proceso Verificación Nombre Descripción
Fórmula Resultado Esperado
Objetivo Plan de Medición
c.
Tasa de Vulnerabilidad La vulnerabilidad en un software es un fallo en la seguridad, a través del cual, un atacante puede comprometer la seguridad de todo el sistema sobre el que se ejecuta la aplicación. Cuando el software está listo para pasar a un ambiente pre-producción, el encargado de operaciones realiza un escaneo de vulnerabilidad con la herramienta Penetration Test, para poder obtener el porcentaje de vulnerabilidad crítica que tiene el software. ((Cantidad de problemas Vulnerabilidad de software) / (Total métodos escaneados de software)) *100 [0 – 2 %> Regular [2 – 10 %> Malo [10 – 100 %] Crítico El resultado esperado del indicador es tener como máximo 2% vulnerabilidad. Reducir el porcentaje de vulnerabilidades de seguridad en el desarrollo de software. Responsable de toma de Analista de Operaciones medición Frecuencia a realizar la Por despliegue de medición aplicación al ambiente de pre-producción. Personas involucradas Analista de Operaciones Jefe de Desarrollo
Descripción de las fuentes de información
Rol de la persona que ejecuta el proceso Analista Comercial
Documento o artefacto que proporciona
Gestión de Requisitos/Actividad2: Definir Requerimiento con el Cliente.
Solicitud de Requerimiento
Analista de Formato de solicitud Implementaciones Requerimiento TI
Actividad en el proceso donde se ejecuta la acción
de
Gestión de Requisitos /Actividad4: Elaborar documento funcional del Requerimiento.
17
Jefe de Proyectos
Cronograma de Requerimiento
Analista Comercial
Orden de Requerimiento
Documento Jefe de Desarrollo Diseño
de
Compra
Análisis
Gestión de Requisitos /Actividad7: Consolidar estimación de esfuerzo de cada área involucrada.
de Gestión de Requisitos /Actividad9: Elaborar Orden de Compra. y
Gestión de Requisitos /Actividad16: Definir solución tecnológica del Requerimiento.
Componentes de Despliegue
Gestión de Desarrollo/Actividad8: Implementar Componentes de Despliegue.
Analista de Desarrollo
Documento Manual de Usuario
Gestión de Desarrollo /Actividad10: Elaborar Documento Manual de Usuario.
Analista de Desarrollo
Gestión de Desarrollo Documento de pase a QA y /Actividad11: Elaborar Documento Producción de pase a QA y Producción.
Analista QA
Plan de Pruebas
Gestión de QA/Actividad2: Elaborar Plan de Pruebas
Asistente QA
Informe de Plan de Pruebas
Gestión de QA/Actividad7: Elaborar Informe de Plan de Pruebas
Analista de Desarrollo
Analista de Acta de Conformidad Implementaciones
d.
Gestión de Ratificación en PreProducción/Actividad5: Elaborar Acta de Conformidad
Evaluación del cumplimiento de las prácticas específicas
Área de Proceso Desarrollo de Requisitos (RD) SG 1 Desarrollar los requisitos de cliente Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
SP 1.1: Educir las necesidade s
¿Cumple Número con la de práctica? actividad en el diagrama de proceso El Analista Comercial recepciona Correo con las FI. Gestión de inicialmente las necesidades del necesidades Requisitos Cliente a través de un mail. del cliente. /Actividad Posterior a ello agendan una 1 reunión para entrar más en 18
detalle. Se suele aplicar la técnica lluvia de ideas. SP 1.2: Trasformar las necesidade s de las partes interesadas en requisitos de cliente.
El Analista Comercial define el Solicitud de FI. Requerimiento del Cliente en Requerimiento base a sus necesidades de negocio. Por lo general, se adjunta prototipos en la Solicitud de Requerimiento.
Gestión de Requisitos /Actividad 2
SG 2 Desarrollar los requisitos de producto Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
¿Cumple Número con la de práctica? actividad en el diagrama de proceso Formato de FI. Gestión de solicitud de Requisitos Requerimiento /Actividad TI 4
SP 2.1: Establecer los requisitos de producto y de component e de producto. SP 2.2: Asignar los requisitos de component e de producto.
El Analista de Implementaciones consolida los requerimientos funcionales en el Formato de solicitud de Requerimiento TI. Asimismo, en base a lo anterior, define los requerimientos no funcionales.
SP 2.3: Identificar los requisitos de interfaz
El Jefe de Desarrollo especifica Documento de FI. la integración de la aplicación Análisis y con otros aplicativos en el Diseño Documento de Análisis y Diseño.
El Jefe de Desarrollo define la Documento de FI. arquitectura de aplicación del Análisis y Requerimiento. Diseño El Jefe de Arquitectura define la arquitectura de datos del Requerimiento.
Gestión de Requisitos /Actividad 16 y Actividad 19, respectiva mente. Gestión de Requisitos /Actividad 16
19
SG 3 Analizar y validar los requisitos Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
SP 3.1: Establecer los conceptos y los escenarios de operación
¿Cumple Número con la de práctica? actividad en el diagrama de proceso El Área de Desarrollo analiza el Documento de FI. Gestión de Requerimiento y define el flujo Análisis y Desarrollo principal y los flujos alternos de Diseño /Actividad la solución en el Documento de 4y5 Análisis y Diseño.
SP 3.2: Establecer una definición de la funcionalid ad y de los atributos de calidad requeridos
El Área de Desarrollo analiza el Documento de FI. Requerimiento, define y Análisis y documenta la solución a Diseño implementar en el Documento de Análisis y Diseño.
Gestión de Desarrollo /Actividad 4y5
SP 3.3: Analizar los Requisitos
El Área de Desarrollo valida el Documento de FI. Documento de Análisis y Diseño. Análisis y Corrobora los prototipos y Diseño verifica que los requisitos funcionales y no funcionales sean estimables y testeables.
Gestión de Desarrollo /Actividad 5
SP 3.4: Analizar los requisitos para conseguir un Requerimi ento
El Analista de Implementaciones consolida y refina (de ser necesario) en el Formato de solicitud de Requerimiento TI, los requerimientos funcionales especificamos en la Solicitud de Requerimiento. Valida que los requerimientos estén alineados con la necesidad del Cliente.
Gestión de Requisitos /Actividad 4 y Actividad 19, respectiva mente.
Formato de FI. solicitud de Requerimiento TI Documento de Análisis y Diseño
El Jefe de Desarrollo valida que la solución definida en el Documento de Análisis y Diseño esté alineada con la necesidad del 20
SP 3.5: Validar los Requisitos
Cliente. El Jefe de Desarrollo analiza los Documento de FI. riesgos de desarrollar la solución Análisis y o tercerizarla dependiendo de la Diseño complejidad y del tiempo que se disponga para ello. Este análisis se especifica en el Documento de Análisis y Diseño.
Gestión de Desarrollo /Actividad 16
Área de Proceso Solución Técnica (TS) SG 1 Seleccionar soluciones de componentes de producto Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
¿Cumple Número con la de práctica? actividad en el diagrama de proceso SP 1.1: El Jefe de Desarrollo evalúa Documento de FI. Gestión de Desarrollar tercerizar o hacer propio el Análisis y Requisitos soluciones desarrollo del Requerimiento, y Diseño. /Actividad alternativas lo define en el Documento de 16 y los Análisis y Diseño. criterios de selección. SP 1.2: Selecciona r las soluciones de component es de producto.
El Jefe de Desarrollo evalúa Documento de FI. tercerizar o hacer propio el Análisis y desarrollo del Requerimiento Diseño. considerando complejidad y tiempo disponible del equipo de Desarrollo. Los criterios y razones de la selección son especificadas en el Documento de Análisis y Diseño.
SG 2 Desarrollar el diseño Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
Gestión de Requisitos /Actividad 16
¿Cumple Número con la de práctica? actividad en el diagrama de 21
SP 2.1: Diseñar el producto o los component es de producto. SP 2.2 Establecer un paquete de datos técnicos.
SP 2.3 Diseñar las interfaces usando criterios. SP 2.4. Realizar los análisis sobre si hacer, comprar o reutilizar.
El Jefe de Desarrollo define la especificación técnica en el Documento de Análisis y Diseño teniendo como referencia los requisitos funcionales y no funcionales definidos en el Formato de solicitud de Requerimiento TI. El Jefe de Desarrollo especifica la arquitectura de la aplicación definida para la implementación del Requerimiento en el Documento de Análisis y Diseño.
Documento de FI. Análisis y Diseño
Documento de FI. Análisis y Diseño
El Jefe de Arquitectura especifica la arquitectura de base de datos y todos los objetos relacionados a ella en el Documento de Análisis y Diseño. El Área de Desarrollo define las Documento de FI. interfaces del desarrollo del Análisis y Requerimiento en el Documento Diseño de Análisis y Diseño. El Jefe de Desarrollo evalúa Documento de FI. tercerizar o hacer propio el Análisis y desarrollo del Requerimiento Diseño considerando complejidad y tiempo disponible del equipo de Desarrollo. Los criterios y razones de la selección son especificadas en el Documento de Análisis y Diseño.
SG 3 Implementar el diseño del producto Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
SP 3.1: Implement ar el diseño
El Área de Desarrollo ejecuta el Componentes desarrollo del Requerimiento, el de despliegue desarrollo de seguridad y la implementación de componentes para el despliegue.
proceso Gestión de Requisitos /Actividad 16
Gestión de Requisitos /Actividad 16 y Actividad 19, respectiva mente.
Gestión de Desarrollo /Actividad 5 Gestión de Requisitos /Actividad 16
¿Cumple Número con la de práctica? actividad en el diagrama de proceso FI. Gestión de Desarrollo /Actividad es 6, 7 y 8
22
SP 3.2: Desarrolla r la Document ación de soporte del producto.
El Área de Desarrollo especifica Documento FI. los detalles técnicos del soporte Manual de de la implementación en el Usuario Documento Manual de Usuario.
Gestión de Desarrollo /Actividad 10
Área de Proceso Integración del Producto (PI) SG 1 Prepararse para la integración del producto. Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
SP 1.1 No aplica. Establecer una estrategia de integració n.
No aplica.
SP 1.2 No aplica. Establecer el entorno de integració n del producto.
No aplica.
¿Cumple Número con la de práctica? actividad en el diagrama de proceso NI. No aplica. No existe actividad en el que se especifique una estrategia de integración.
NI. No existe actividad en el que se especifique los requisitos del entorno de integración del producto. SP 1.3 El Analista de Desarrollo define Documento PI. Establecer los procedimientos y los criterios de pase a QA No existe los de integración del producto en el y Producción actividad en
No aplica.
Gestion de Desarrollo /Actividad 23
procedimi Documento de pase a QA y entos y los Producción. criterios de integració n del producto.
el que se 11 defina los procedimie ntos y criterios de integración del producto en el ambiente de Desarrollo.
SG 2 Asegurar la compatibilidad de las interfaces. Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
SP 2.1 Revisar la completitu d de las descripcio nes de las interfaces. SP 2.2 Gestionar las interfaces.
¿Cumple Número con la de práctica? actividad en el diagrama de proceso El Jefe de Desarrollo define las Documento FI. Gestión de estructuras de las interfaces y la de Análisis y Desarrollo interacción del Requerimiento Diseño. /Actividad implementado con otros sistemas 5 en el Documento de Análisis y Diseño. El Jefe de Desarrollo analiza el requerimiento consultando el Formato de solicitud de Requerimiento TI y define la estructura de las interfaces en el Documento de Análisis y Diseño.
Formato de FI. solicitud de Requerimient o TI
Gestión de Desarrollo /Actividad es 4 y 5
Documento de Análisis y Diseño
SG 3 Ensamblar los componentes de producto y entregar el producto. Práctica Descripción del proceso actual Entregables ¿Cumple Número específica que cumple con el propósito la del proceso con la de práctica específica práctica? actividad en el diagrama de proceso SP 3.1 No aplica. No aplica. NI. No aplica. Confirmar No existe la actividad en 24
disponibili dad de los componen tes de producto para la integració n. SP 3.2 Ensamblar los componen tes de producto. SP 3.3 Evaluar los componen tes de producto ensamblad os. SP 3.4 Empaquet ar y entregar el producto o componen te de producto.
El Analista de Operaciones realiza el despliegue de la aplicación siguiendo los pasos especificados en el Documento de pase a QA y Producción. No aplica.
El Analista de Operaciones realiza el despliegue al ambiente de Producción siguiendo los pasos especificados en el Documento de pase a QA y Producción. Por último, notifica conformidad de despliegue. El Analista de Implementaciones envía el Documento Manual de Usuario al Cliente.
el que se especifique que el producto cumple con los criterios de aceptación. Documento FI. Gestión de de pase a QA Despliegu y Producción e/Activida d3 No aplica.
NI. No aplica. No existe actividad en el que se evalúe el producto desplegado en producción. Documento FI. Gestión de de pase a QA Despliegu y Producción e/Activida d8 Documento Manual de Gestión de Usuario Ratificació n en PreProducció n/Activida d1
Área de Proceso Verificación (VER) SG 1 Preparar la verificación Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
SP
1.1 No aplica.
No aplica.
¿Cumple Número con la de práctica? actividad en el diagrama de proceso NI. No aplica. 25
Selecciona r los productos de trabajo para la verificació n
No existe actividad en el que se especifique el producto o componente s a verificar. El área de QA verifica todo el producto. SP 1.2 No aplica. No aplica. NI. No aplica. Establecer No existe el entorno actividad en de el que se verificació especifique n. los requisitos del entorno de verificación . SP 1.3 El Analista QA define los Plan de FI. Gestión de Establecer procedimientos y criterios de Pruebas QA/Activi los verificación en el Plan de Pruebas. dades2 procedimi entos y los criterios de verificació n.
SG 2 Realizar las revisiones ente pares Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
SP 2.1 No aplica. Preparar las revisiones entre pares SP 2.2 No aplica. Realizar
No aplica.
No aplica.
¿Cumple Número con la de práctica? actividad en el diagrama de proceso NI. No aplica. No se aplica revisión entre pares. NI. No aplica. No se aplica 26
las revisiones entre pares. SP 2.3 No aplica. Analizar los datos de las revisiones entre pares
revisión entre pares. No aplica.
NI. No aplica. No se aplica revisión entre pares.
SG 3 Verificar los productos de trabajo seleccionados Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
SP 3.1 Realizar la verificació n
El Analista de QA valida el Plan código a través del Sistema Pruebas Veracode. Si no existe observaciones, el Asistente de QA, adicional al paso anterior, ejecuta el Plan de Pruebas.
SP 3.2 analizar los resultados de la verificació n
El Sistema Veracode genera un Informe de Validación de código el cual es analizado por el Analista QA para elaborar el Informe de Plan de Pruebas. Los resultados de la ejecución del Plan de Pruebas también son analizados para complementar el Informe de Plan de Pruebas.
de
Informe de Validación de código Informe Plan Pruebas
de de
¿Cumple Número con la de práctica? actividad en el diagrama de proceso PI. Gestión de No existe QA/Activi actividad en dades 3, 5 el que se y 6 especifique la verificación de etapas previas. PI. Gestión de No existe QA/Activi actividad en dades 4, 5, el que se 6 y 7 especifique la verificación de etapas previas.
Área de Proceso Validación (VAL) SG 1 Preparar la validación Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
¿Cumple Número con la de práctica? actividad en el 27
SP 1.1: No aplica. Selecciona r los productos para la validación .
SP 1.2: Establecer el entorno de validación .
SP 1.3: Establecer los procedimi entos y los criterios de validación
No aplica.
NI. No existe actividad en el que se especifique el producto o component es a validar. El cliente valida funcionalm ente todo el producto. No aplica. No aplica. NI. No existe actividad en el que se especifique los requisitos del entorno de validación. El Analista Comercial define los Solicitud de PI. criterios de aceptación en la Requerimient No existe Solicitud de Requerimiento. o actividad en el que se especifique los procedimie ntos de validación.
SG 2 Validar el producto o los componentes de producto Práctica Descripción del proceso actual Entregables específica que cumple con el propósito la del proceso práctica específica
SP 2.1: No aplica. Realizar la
No aplica.
diagrama de proceso No aplica.
No aplica.
Gestión de Requisitos /Actividad 2
¿Cumple Número con la de práctica? actividad en el diagrama de proceso NI. No aplica. No existe 28
validación .
SP 2.2: No aplica. Analizar los resultados de la validación .
e.
No aplica.
actividad en el que se documente los procedimie ntos tal y como se ejecutaron ni actividad en el que se registre los datos resultantes de la validación. NI. No aplica. No existe actividad en el que se analice los resultados de la validación del cliente.
Presentación de resultados a) Resumen total de la evaluación en área de proceso por meta específica A continuación, por cada área de proceso y meta específica se presenta un resumen total según la caracterización de la evaluación SCAMPI A de cada práctica específica.
29
Figura 14. Resumen total de la evaluación en PA por SG Recuperado de: “una adaptación propia” Por otro lado, por cada área de proceso se presentan los siguientes cuadros que indican el porcentaje de cumplimiento de cada meta y práctica específica. - Para las prácticas específicas se considera el cumplimiento total como equivalente al 100%, el cumplimiento parcial equivalente al 50% y el incumplimiento equivalente al 0%. Cumplimiento de las prácticas específicas en % Cumplimiento total Cumplimiento parcial No cumple 100% 50% 0% -
Para las metas específicas se considera 100% cuando todas sus prácticas especificas están cumplidas totalmente (100%), caso contrario se considera 0%.
Área de Proceso Desarrollo de Requisitos (RD) SG 1 Desarrollar requisitos de cliente SP 1.1 SP 1.2
los Cumplimiento
SG 2 Desarrollar requisitos de producto SP 2.1 SP 2.2 SP 2.3
los Cumplimiento
100% 100%
100% 100% 100%
TOTAL 100%
TOTAL 100%
30
SG 3 Analizar y validar los Cumplimiento requisitos SP 3.1 100% SP 3.2 100% SP 3.3 100% SP 3.4 100% SP 3.5 100%
TOTAL 100%
Área de Proceso Solución Técnica (TS) SG 1 Seleccionar soluciones Cumplimiento de componentes de producto SP 1.1 100% SP 1.2 100%
TOTAL
SG 2 Desarrollar el diseño SP 2.1 SP 2.2 SP 2.3 SP 2.4
Cumplimiento 100% 100% 100% 100%
TOTAL 100%
SG 3 Implementar el diseño Cumplimiento del producto SP 3.1 100% SP 3.2 100%
TOTAL
100%
100%
Área de Proceso Integración del Producto (PI) SG 1 Prepararse para la Cumplimiento integración del producto SP 1.1 0% SP 1.2 0% SP 1.3 50%
TOTAL
SG 2 Asegurar compatibilidad de interfaces SP 2.1 SP 2.2
TOTAL
la Cumplimiento las 100% 100%
0%
100%
31
SG 3 Ensamblar los componentes de producto y entregar el producto SP 3.1 SP 3.2 SP 3.3 SP 3.4
Cumplimiento
TOTAL
0% 100% 0% 100%
0%
Cumplimiento 0% 0% 100%
TOTAL 0%
SG 2 Realizar la revisión Cumplimiento entre pares SP 2.1 0% SP 2.2 0% SP 2.3 0%
TOTAL
SG 3 Verificar los productos Cumplimiento de trabajo seleccionado SP 3.1 50% SP 3.2 50%
TOTAL
Área de Proceso Verificación (VER) SG 1 Preparar la validación SP 1.1 SP 1.2 SP 1.3
0%
0%
Área de Proceso Validación (VAL) SG 1 Preparar la validación SP 1.1 SP 1.2 SP 1.3
Cumplimiento 0% 0% 50%
TOTAL 0%
SG 2 Validar el producto o Cumplimiento los componentes de producto SP 2.1 0% SP 2.2 0%
TOTAL 0%
32
b) % Total de prácticas evaluadas por caracterización de la evaluación SCAMPI A
Figura 15. Participación de prácticas evaluadas por caracterización de evaluación SCAMPI A Recuperado de: “una adaptación propia” Desarrollo de Requisitos (RD) Area
Metas
Práctic a
RD RD
SG 1
RD
SG 1
SP 1.1
RD
SG 1
SP 1.2
RD
SG 2
RD
SG 2
SP 2.1
Descripción Desarrollo de requerimientos RD Desarrollar los requisitos de cliente Educir las necesidades (ejm: prototipo). Trasformar las necesidades de las partes interesadas en requisitos de cliente Desarrollar los requisitos de producto Establecer los requisitos de producto y de componente de producto
NY
NI
PI
LI
FI
x x
x
33
RD
SG 2
SP 2.2
RD
SG 2
SP 2.3
RD
SG 3
RD
SG 3
SP 3.1
RD
SG 3
SP 3.2
RD
SG 3
SP 3.3
RD
SG 3
SP 3.4
RD
SG 3
SP 3.5
Asignar los requisitos de componente de producto Identificar los requisitos de interfaz (internas, externas) Analizar y validar los requisitos Establecer los conceptos y los escenarios de operación Establecer una definición de la funcionalidad y de los atributos de calidad requeridos (análisis funcional) Analizar los requisitos
x
Analizar los requisitos para conseguir un equilibrio Validar los requisitos
x
x
x x
x
x
Solución Técnica TS Area
Metas
Práctic a
TS TS
SG 1
TS
SG 1
SP 1.1
TS
SG 1
SP 1.2
TS TS
SG 2 SG 2
SP 2.1
TS
SG 2
SP 2.2
TS
SG 2
SP 2.3
TS
SG 2
SP 2.4
TS
SG 3
TS
SG 3
SP 3.1
TS
SG 3
SP 3.2
Descripción Solución Técnica TS Seleccionar soluciones de componentes de producto Desarrollar soluciones alternativas y los criterios de selección. Seleccionar las soluciones de componentes de producto Desarrollar el diseño Diseñar el producto o los componentes de producto. Establecer un paquete de datos técnicos. Diseñar las interfaces usando criterios Realizar los análisis sobre si hacer, comprar o reutilizar Implementar el diseño del producto Implementar el diseño Desarrollar la Documentación de soporte del producto.
NY
NI
PI
LI
FI
x x x x x x
x x
34
Integración del Producto PI Area
Metas
Práctic a
PI PI
SG 1
PI
SG 1
SP 1.1
PI
SG 1
SP 1.2
PI
SG 1
SP 1.3
PI
SG 2
PI
SG 2
SP 2.1
PI
SG 2
SP 2.2
PI
SG 3
PI
SG 3
SP 3.1
PI
SG 3
SP 3.2
PI
SG 3
SP 3.3
PI
SG 3
SP 3.4
Descripción
NY
Integración del Producto PI Prepararse para la integración del producto Establecer una estrategia de integración. Establecer el entorno de integración del producto Establecer los procedimientos y los criterios de integración del producto. Asegurar la compatibilidad de las interfaces Revisar la completitud de las descripciones de las interfaces. Gestionar las interfaces.
NI
PI
LI
FI
x x x
x x
Ensamblar los componentes de producto y entregar el producto Confirmar la disponibilidad de los componentes de producto para la integración. Analizar los resultados de la verificación Evaluar los componentes de producto ensamblados. Empaquetar y entregar el producto o componente de producto.
x x x x
Verificación VER Area
Metas
Práctic a
VER VER VER
SG 1 SG 1
SP 1.1
VER
SG 1
SP 1.2
VER
SG 1
SP 1.3
VER
SG 2
Descripción Verificación VER Preparar la validación Seleccionar los productos de trabajo para la verificación Establecer el entorno de verificación. Establecer los procedimientos y los criterios de verificación Realizar las revisiones ente
NY
NI
PI
LI
FI
x x x
35
VER
SG 2
SP 2.1
VER
SG 2
SP 2.2
VER
SG 2
SP 2.3
VER
SG 3
VER VER
SG 3 SG 3
SP 3.1 SP 3.2
pares Preparar las revisiones entre pares Realizar las revisiones entre pares. Analizar los datos de las revisiones entre pares Verificar los productos de trabajo seleccionados Realizar la verificación Analizar los resultados de la verificación
x x x
x x
Validación VAL Area
Metas
Práctic a
VAL VAL VAL
SG 1 SG 1
SP 1.1
VAL
SG 1
SP 1.2
VAL
SG 1
SP 1.3
VAL
SG 2
VAL
SG 2
SP 2.1
VAL
SG 2
SP 2.2
Descripción Validación VAL Preparar la validación Seleccionar los productos para la validación Establecer el entorno de validación Establecer los procedimientos y los criterios de validación Validar el producto o los componentes de producto Realizar la validación. Analizar los resultados de la validación
NY
NI
PI
LI
FI
x x x
x x
c) Resultados de Evaluación por Área de Proceso A continuación, se presentan los resultados de la evaluación por Área de Proceso.
36
Figura 16. Resultados de evaluación por PA Recuperado de: “una adaptación propia” Según la evaluación de cumplimiento de las practicas RD, TS, PI, VER y VAL bajo la evaluación SCAMPI, no se llega a alcanzar el nivel 3 del proceso de desarrollo de software. d) Oportunidades de mejora en las áreas de proceso y/o prácticas específicas que no cumplan con lo requerido en el modelo CMMI. A continuación, se detallan las oportunidades de mejora por meta específica de cada área de proceso que no cumpla con lo requerido en el modelo CMMI.
37
PA SG Oportunidades de mejora INTEGRACIÓN DEL PRODUCTO SG Implementar estrategia de integración: el cual permita definir y 1 especificar la estrategia de integración en los 3 ambientes (desde Desarrollo hasta Producción) y especificar los requisitos del entorno de integración. SG Implementar gestión de integración: el cual permita identificar y 3 especificar los componentes que cumplen con la estrategia y procedimientos de integración para su ensamblaje y evaluar el producto ya en producción según los criterios de integración. VERIFICACIÓN SG Implementar gestión de entorno de verificación: el cual permita 1 identificar y especificar el producto o componentes a verificar y los requisitos del entorno de verificación. SG Implementar revisión de pares: el cual permita planificar, ejecutar y 2 analizar los resultados de la revisión de pares. SG Implementar gestión de verificación integra: el cual permita verificar 3 que todas las etapas del desarrollo del software se realizan correctamente, es decir, desde la captura de requisito hasta la entrega del producto al cliente. VALIDACIÓN SG Implementar gestión de entorno de validación: el cual permita 1 identificar y especificar el producto o componentes a validar, los requisitos del entorno de validación y los procedimientos de validación a seguir por el Cliente. SG Implementar gestión de validación del cliente: el cual permita 2 identificar los procedimientos seguidos por el cliente en la validación, el registro de los resultados de la propia validación y el análisis de estos. f.
Plan de implementación de mejoras Con respecto al modelo IDEAL, se añade lo siguiente: Fase Iniciando Se plantea implementar las pruebas de pares en la etapa de desarrollo del software (Solución Técnica), con el enfoque a mejorar la calidad del entregable y reducir el margen de error encontrado por el equipo de QA, con ello también agilizaremos los tiempos de pruebas. Fase Diagnosticando En el proceso actual no se realizan las pruebas de pares y en algunos desarrollos existen muchas devoluciones de entregables por el equipo de QA. Ello debido que este último encuentra demasiados errores en los desarrollos durante la etapa inicial de pruebas (pruebas de humo). Así mismo, se identifica como fortaleza que el equipo de desarrollo se encuentra predispuesto a mejorar este evento, como debilidad se ha 38
encontrado que el equipo no se encuentra capacitado para realizarlo y como oportunidad se identifica que existe mucha información con respecto a ello. Con respecto a las métricas, actualmente el 30% de los entregables tiene este comportamiento, lo cual queda registrado en el informe de pruebas. Fase Estableciendo Con respecto a las actividades a realizar a nivel estratégico, se plantea implementar un plan de capacitaciones con respecto a pruebas de pares, se podría evaluar trabajar con un proveedor externo (capacitador) o adquirir cursos online. Con respecto a nivel operario, se plantea difundir el plan de capacitaciones y llevar un seguimiento de los resultados que pueda tener esta implementación. Fase Actuando Se propone implementar el plan de capacitaciones, fechas, horarios y los involucrados. Así mismo, el análisis del aterrizaje de todo lo aprendido en la aplicación de las actividades que se dispone a mejorar. Se propone que trimestralmente se debe obtener métricas para validar el avance de lo implementado. Fase Aprendiendo Se identificó que involucrando y escuchando a todas las personas relacionadas con las áreas afectadas, se puede obtener información más valiosa para el plan de cambios. Con respecto al plan de mejoras, se propone involucrar en la parte de actuando a los ejecutores del proceso, con el sentido de añadir mayor valor. Así mismo, se propone añadir la siguiente métrica, con el sentido de monitorizar los entregables de desarrollo hacia QA y poder reducir la cantidad de devoluciones. Nombre Descripción
Fórmula Resultado Esperado
Objetivo
Tasa de devoluciones de desarrollos Se tiene una cantidad de desarrollos (entregables) promedio que el equipo de QA puede devolver hacia desarrollo, de superar esta cantidad durante las pruebas, indica que durante la fase de desarrollo existen ciertas deficiencias. Número de devoluciones (iteraciones) [0 – 3> Regular [3 – 5> Malo [<5] Crítico El resultado esperado del indicador es tener como máximo 3 devoluciones. Reducir el número de devoluciones de desarrollos por parte del equipo de QA. Responsable de toma de Analista de Desarrollo
39
Plan de Medición
g.
medición Frecuencia a realizar la Por desarrollo (nuevos medición requerimientos) Personas involucradas Analista de Desarrollo Analista de QA Asistente de QA
Conclusiones
Según la evaluación del cumplimiento de prácticas RD, TS, PI, VER y VAL del modelo CMMI bajo la evaluación SCAMPI, el proceso Desarrollo de Software de la
empresa Sentinel Perú S.A. no alcanza el nivel 3 de madurez. Se definen y se sugiere implementar oportunidades de mejora para las áreas de
proceso que no se cumple con lo requerido en el modelo CMMI. Dentro de la evaluación de cumplimiento de prácticas de CMMI, la empresa SENTINEL, se preocupa por la toma de requerimientos que entrega el cliente, y por el desarrollo del diseño e implementación del producto. Además, estos procesos los complementa con diferentes tipos de documentación, suficiente para asegurar una buena toma de requisitos y desarrollo del producto en todas las fases de diseño
e implementación. Con respecto a las prácticas de Validación y Verificación, se ha encontrado que hay mucho trabajo por hacer en cuanto a la inclusión de los artefactos correctos y los escenarios no contempladas dentro de los procesos internos. Si bien, existen procedimientos que brindan los resultados necesarios para cubrir estos aspectos, éstos no cumplen la trazabilidad que CMMI exige dentro de sus prácticas y por
consiguiente no satisfacen las demandas de madurez. El monitoreo que realiza la organización brinda una mayor escalabilidad al encontrar oportunidades de mejora dentro de los procesos de desarrollo. No obstante, hace falta la guía que brinda CMMI para el seguimiento a tiempo real sobre las acciones correctivas a las incidencias que suceden dentro algunos de los
procesos de SENTINEL. Gracias a CMMI la empresa tiene la oportunidad de mejorar aún más su buena imagen institucional y esto debe aprovecharse para atraer mayor cantidad de
clientes. La empresa está preparada para iniciar el proceso de validación de sus procesos a
un nivel de madurez suficiente para las primeras etapas con CMMI. Se proyecta tener una ventaja competitiva al adoptar las metodologías de CMMI.
40
h.
Referencias Bibliográficas
Chrissis, M., Konrad, M., & Shrum, S. (2009). Guía para la integración de procesos y la mejora de productos. Estados Unidos: Addison Wesley. Software Engineer Institute. (2010). CMMI para Desarrollo, Versión 1.3. España: Editorial Universitaria Ramón Areces. Suárez, B. (22 de junio de 2017). Ejemplos de Metodología Ishikawa. Recuperado de https://www.problemsolving.pro/ejemplos-de-metodologia-ishikawa/ [Consulta: 04 de junio de 2020]. Torres, C., & Arbeláez, D. (2008). Guía de implantación de CMMI en la empresa de software
colombiana.
Recuperado
de
https://repository.eafit.edu.co/bitstream/handle/10784/2711/TorresVelasquez_Cesar _2008.pdf?sequence=1 [Consulta: 01 de junio de 2020].
41
i.
Anexos
Anexo 1
42
Anexo 2
43
Anexo 3
44
Anexo 4
45
Anexo 5
46
Anexo 6
47
Anexo 7
48
Anexo 8 Cronográma-CMMI
49
