Proyecto CMMI

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