aplicación del modelo cmmi nivel 2, scrum y psp para el desarrollo de software presentado por:...

Aplicación del Modelo CMMI nivel 2, SCRUM y PSP para el desarrollo

de Software

Presentado por: Raúl Castro Castillo

Universidad Nacional de Ingeniería, Facultad de Ingeniería Industrial y de Sistemas

TESIS

Para optar por el título de Ingeniero de Sistemas

Aplicación del CMMI, SCRUM, PMBOK y PSP

Universidad Nacional de Ingeniería

Contenido

1. Introducción2. Definición de Problemas y Objetivos3. Marco Teórico4. Obtención del Modelo Integrado5. Aplicación del Modelo6. Análisis de Resultados7. Conclusiones y Recomendaciones



Introducción1

Universidad Nacional de Ingeniería 4


¿Tienes alguno de estos problemas?

Presupuestos irreales Cronogramas irreales y

vencidos Cambios de alcance o

cronograma excesivos Comunicación pobre Cerca al final del

proyecto todo se atrasa Mala calidad Baja moral

No se sabe qué es lo que se debe hacer

Mucho sobre tiempo y re trabajo

Muchas reuniones Reinventas la rueda en

cada proyecto Clientes descontentos Productos que no se usan Pérdidas de

clientes/negocios



¿Que necesitaba realmente el usuario?



Resumen de la Tesis

El problema, objetivos e hipótesis

Obtención del Modelo

IntegradoAplicación del

ModeloValidación de la

hipótesis



Definición del Problema y Objetivos

2



Definición del Problema

Entrega de productos de software de mala calidad, con cronogramas retrasados, con costos que exceden los presupuestos.

Mala Calidad

Presupuestos Irreales

Cronogramas

vencidos

Cambios Excesivos

Trabajo Excesivo Retrabajo Comunicac

ión Pobre



Objetivo General

Crear un modelo integrado que permita desarrollar productos software de Calidad, con costos y cronogramas razonables que cumplan las expectativas de los clientes o usuarios.

Objetivos Específicos

• Contar con procesos de desarrollo de software que permitan obtener productos de mayor calidad. • Desarrollar procesos y estándares para la gestión de requerimientos • Desarrollar mecanismos de mediciones constantes para detectar posibles distorsiones • Desarrollar los requerimientos en base a entregas iterativas• Hacer que los integrantes del equipo siempre opten por la reutilización• Incrementar la productividad de los desarrolladores• Contar con técnicas para realizar estimaciones más exactas• Disminuir el tiempo de pruebas



Hipótesis

“El empleo de un enfoque integrado del Modelo de Mejora de Procesos CMMI, las buenas prácticas del PMBOK®, el Marco de Referencia SCRUM bajo su enfoque ágil y el PSP que mejora la

forma de trabajo personal, permite gestionar y desarrollar proyectos con mayor calidad, con costos y tiempos adecuados, mejorar el desempeño y la comunicación en los integrantes del

equipo de desarrollo.”



Variables a Medir

Tiempos y esfuerzos estimados contra los

tiempos y esfuerzos reales de un proyecto.

Costos incurridos en el desarrollo de un proyecto

versus los estimados.

Productividad de los desarrolladores en base a medidas de tamaño del

producto a construir.

Número de requerimientos desarrollados

adecuadamente.

Número de defectos encontrados en la fase de

pruebas de software y número de errores

encontrados en producción.

Tiempo total de pruebas con respecto al total de tiempo de desarrollo del

proyecto.

Yield de los desarrolladores,



Marco Teórico3



Marco Teórico

CMMI

SCRUM

PSP

PMBOK

Métrica V3



CMMI

El Capability Maturity Model Integration (CMMI) es un marco de referencia que las organizaciones pueden emplear para mejorar sus procesos de desarrollo, adquisición, y mantenimiento de productos y servicios.

Nacido en el Software Engineering Institute perteneciente a la Carnegie Mellon University.



CMMI Niveles de Madurez



Áreas de Proceso



CMMI Arquitectura del Modelo

• Áreas de Proceso• Metas genéricas• Metas específicas• Prácticas genéricas• Prácticas específicas• Sub prácticas



SCRUM

• Es un marco de referencia para la gestión de proyectos que se basa en los principios ágiles:

– Colaboración estrecha con el cliente.– Predisposición y respuesta al cambio– Desarrollo incremental con entregas funcionales frecuentes– Comunicación verbal directa entre los implicados en el proyecto– Motivación y responsabilidad de los equipos por la auto-gestión,

auto-organización y compromiso.



Contenido de SCRUM



Gallinas y Cerdos

Involucrado versus Comprometido

Scrum diferencia claramente entre estos dos grupos para garantizar que quienes tienen la responsabilidad tienen también la autoridad necesaria para poder lograr

el éxito, y que quienes no tienen la responsabilidad no producen interferencias innecesarias



El flujo de SCRUM



La comunicación en SCRUM

Reunión diaria

Revisión del sprint

Reunión retrospectiva



PSP(Personal Software Process)

Metodología de Ingeniería de Software, basada en principios y prácticas del modelo CMMI diseñada para ayudar a Ingenieros de Software a producir software de calidad.

Ayuda a la estimación, planeación y desarrollo de sistemas de software.

Orientada a manejar la mejora continua de las habilidades.



En que nos ayuda PSPPlanes precisos.

Pasos a seguir para mejorar la calidad.

Bancos de datos para medir mejora.

Asignación de tiempo al diseño.

Asignación de tiempo para revisiones e inspecciones.

Seguimiento.

7. Compromiso



PSP Niveles



Formularios

• PSP proporciona una serie de formatos divididos en formularios, scripts del proceso, plantillas para el registro de eventos y estándares.



PSP El proceso



PMBOK

PMI ha reunido los conocimientos, técnicas y prácticas vigentes, para la gestión exitosa de proyectos en un documento llamado PMBOK (Project Management Body of Knowledge).

El propósito principal del PMBOK es identificar el conocimiento de Gestión de Proyectos que es generalmente aceptado como buena práctica.



PMBOK Procesos

Definición actividades

Secuenciación actividades

Estimación de recursos

Iniciación Planificación Ejecución Control Cierre

Gestión de compras

Gestión de riesgos

Gestión de la comunicación

Gestión de RRHH

Gestión de costos

Gestión del tiempo

Gestión de la calidad

Gestión del alcance

Gestión de integración

Ges

tión

de la

co

nfigu

raci

ón

Recopilar requisitos

Definición alcance

Verificación alcance

Control cambio alcance

Desarrollo plan proyecto

Ejecución plan proyecto

Control global cambios

Planificación calidad Garantía calidad Control calidad

Estimación duración

actividades

Desarrollo programación

Control programación

Estimación costos

Presupuesto costos

Control de costos

Planificación organizativa

Planificación comunicaciones

Distribución información

Reporte rendimiento

Identificación riesgos

Análisis cualitativo

Análisis cuantitativo

Control medidas

Planificación compras

Planificación contratación

Solicitar respuesta

s

Gestión proveedor

esCierre contratos

Planeación de riesgos

Planes de respuestas

Cierre de proyecto

Creación EDT

Gestionar a los interesados

Supervisa y controlar el

trabajo

Identificar interesados

Administrar contratos

Efectuar adquisiciones

Procesos originales Procesos eliminadosProcesos con cambio de

nombre Procesos nuevos

Incorporación personal

Desarrollo de equipo

Gestión de

equipo

Acta proyecto

Enunciado preliminar de alcance



Métrica 3Métrica 3 es una metodología desarrollada y promovida por el Ministerio de Administraciones Públicas del Gobierno de España para la planificación, desarrollo y mantenimiento de sistemas informáticos para la gestión de actividades del ciclo de vida de los proyectos software dentro de las Administraciones Públicas

• Contar con procesos de desarrollo de software que permitan obtener productos de mayor calidad. • Desarrollar procesos y estándares para la gestión de requerimientos • Desarrollar mecanismos de mediciones constantes para detectar posibles distorsiones • Desarrollar los requerimientos en base a entregas iterativas• Hacer que los integrantes del equipo siempre opten por la reutilización• Incrementar la productividad de los desarrolladores• Contar con técnicas para realizar estimaciones más exactas• Disminuir el tiempo de pruebas

Objetivos• Proporcionar o definir sistemas de información que ayuden a conseguir los

fines de la organización.• Dotar a la organización de productos software.• Mejorar la productividad de los departamentos de sistemas y tecnologías de la

información y las comunicaciones.• Facilitar la comunicación y entendimiento entre los distintos participantes en la

producción de software.• Facilitar la operación, mantenimiento y uso de los productos software

obtenido.



Métrica v3 - Estructura



Obtención delModelo Integrado

4



Esquema General

Definición de Requerimientos

Lanzamiento del Proyecto

Gestión de Requerimientos

Gestión del Proyecto

Desarrollo de actividades del Proyecto

N Iteraciones

Ingeniería de Requerimientos

Project Managment

Ingeniería de Software



Esquema General

Definición de Requerimientos

Lanzamiento del Proyecto

Gestión de Requerimientos

Gestión del Proyecto

Desarrollo de actividades del Proyecto

N Iteraciones

CMMI

SCRUM

PMBOK

PSP

MÉTRICA 3



Estructura del ModeloPolíticas

Procesos

Artefactos

Estructura de Roles

Los Elementos del Modelo

Supuestos del Modelo



Supuestos del Modelo

• Para la aplicación del Modelo se hace las siguientes asunciones:

No contempla la formulación de Requerimiento de Negocios. Se asume que el requerimiento de negocio ya ha sido formulado por una necesidad de la organización.

El modelo no contempla el estudio de viabilidad del proyecto. Se asume que el proyecto es viable y que se posee la capacidad para poder desarrollar el proyecto.



Estructura de Roles



Definición de PolíticasPolíticas de Gestión de Requerimientos

Políticas de Planificación de Proyectos

Políticas de Construcción de Software

Políticas de Seguimiento y Control

Políticas de Medición y Análisis

Políticas relacionadas a la Calidad

Políticas relacionadas a la Gestión de la Configuración

Políticas relacionadas a la Gestión de Cambios



Mapa de Procesos



Definición de Procesos



Definición de Artefactos



Mapeo de Procesos y Entregables



Aplicación del ModeloIntegrado

5



Presentación de la Empresa

Grupo Crosland

Crosland Técnica

Crosland Motos

El Sitio

Lima Waterparks

Crosland Logística

Crosland Finanzas

Inca Rail

El Grupo Crosland es un grupo de empresas que tienen distintos rubros de negocios, está constituido por capitales peruanos al 100%. Sus negocios más sobresalientes son: Maquinaria pesada, Turismo y Automotriz



Presentación del Área

Jefe de Sistemas

Jefe de Desarrollo

DBA

Analistas de Sistemas

Desarrolladores

Testing y Documentadores

Calidad Jefe de Soporte

Soporte de Redes

Soporte de Servidores

Soporte de Equipos

OYM

Accesos

El área de sistema de Crosland, está conformado por alrededor de 24 personas las cuales están distribuidos en tres de las sucursales de la empresa del Grupo (Lima, Callao y Cusco).



Selección de Proyectos

Nombre del Proyecto Utilizó el Modelo

Valoración de Empresa Si

Extranet Crosland Si

Sistema de Presupuestos No

Sistema de Punto de Venta Si

Sistema de Gestión Comercial No

Para la aplicación y ejecución del modelo definido, se han seleccionado 5 proyectos, de los cuales en tres de ellos se ha utilizado el modelo y los otros dos se desarrollaron sin utilizar el modelo.



Análisis de Resultados6



Recopilación de Datos

Proyecto Tiempo Estimado Tiempos Reales

Gestión Comercial 6 13

Sistema de Presupuestos 6 11

Valoración de Empresas 6 8

Sistema de Puntos de Venta 5 7

Extranet Crosland 8 9

Tiempos Estimados Vs Tiempo Reales



Análisis de Datos

Gestión Comercial Sistema de Presupuestos Valoración de EmpresasSistema de Puntos de Venta Extranet Crosland0

2

4

6

8

10

12

14

6 6 6

5

8

13

11

8

7

9

Tiempos Estimados vs Reales

Tiempo Estimado Tiempos Reales




Costos Estimados Vs Tiempo Reales

Proyecto Costo Estimado Costos Reales








Análisis de Datos

Gestión Comercial Sistema de Presupuestos Valoración de Empresas Sistema de Puntos de Venta

Extranet Crosland0

20000

40000

60000

80000

100000

120000

140000

7000065000

8000075000

85000

120000

105000100000

80000

90000

Costos Estimados vs Reales

Costo Estimado Costos Reales




Alcance Estimado VS Alcance Real

Proyecto Variación del Alcance

Gestión Comercial Variación del 150% del alcance inicial

Sistema de Presupuestos Variación de casi el 120% del alcance inicial

Valoración de Empresas Variación del 60% del alcance inicial

Sistema de Puntos de Venta Variación del 45% del alcance inicial

Extranet Crosland Variación del 30% del alcance inicial



Análisis de Datos

Gestión Comercial Sistema de Presupuestos Valoración de EmpresasSistema de Puntos de Venta Extranet Crosland0

50

100

150

200

250

300

Variación del Alcance

Alcance Estimado Variación




Número de RQM desarrollados correctamente

Proyecto Total de RQM RQM Aceptados








Análisis de Datos

Gestión Comercial Sistema de Presupuestos Valoración de Empresas Sistema de Puntos de Venta

Extranet Crosland0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

70.00%

80.00%

90.00%

100.00%

% RQM Aceptados

% RQM Aceptados




Densidad de Defectos de los productos en Producción

Proyecto Total de Funcionalidades Total de defectos








Análisis de Datos

Gestión Comercial Sistema de Presupuestos Valoración de EmpresasSistema de Puntos de Venta Extranet Crosland0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

Densidad de Defectos

Densidad de Defectos




Tiempo de testing con respecto al tiempo total de desarrollo

Proyecto Tiempo Total Total en Testing








Análisis de Datos

Gestión Comercial Sistema de Presupuestos Valoración de EmpresasSistema de Puntos de Venta Extranet Crosland0.00%

5.00%

10.00%

15.00%

20.00%

25.00%

30.00%

35.00%

40.00%

45.00%

%Tiempo en Testing

%Tiempo en Testing




Número de defectos encontrados antes de la fase de testing

ProyectoTotal de defectos hasta la fase de

testing

Total de defectos encontrados antes de

testing








Análisis de Datos

Gestión Comerc

ial

Sistem

a de P

resupuest

os

Valorac

ión de Empres

as

Sistem

a de P

untos de V

enta

Extra

net Cro

sland

0

10

20

30

40

50

60

70

80

Defectos encontrados antes de testing

Total de defectos hasta la fase de testing Total de defectos encontrados antes de testing




Productividad de los Desarrolladores

Proyecto Productividad de los desarrolladores

Gestión Comercial No se controla productividadSistema de Presupuestos No se controla productividadValoración de Empresas 20 líneas de código fuente por minutoSistema de Puntos de Venta 30 líneas de código fuente por minuto.Extranet Crosland 50 líneas de código fuente por minuto.




Yield de los Desarrolladores

Proyecto Yield Promedio

Valorización de Empresas 0%

Extranet Crosland 0%

Sistema de Presupuestos 20%

Sistema de Puntos de Venta 25%

Gestión Comercial 30%



Análisis de Datos

Valorización de Empresas Extranet Crosland Sistema de Presupuestos Sistema de Puntos de Venta

Gestión Comercial0%

5%

10%

15%

20%

25%

30%

35%

Yield Promedio

Yield Promedio



Ventajas de Usar el Modelo

• Demanda realizar una descomposición estructurada del trabajo.• Obliga hacer planificaciones de todos los recursos.• Proporciona técnicas para la estimación de tiempos y costos.• Existe también interacción mas seguida con el usuario final.• Proporciona mecanismos de medición de los avances del proyecto.• Exige realizar la gestión de la configuración de los entregables.• Contiene un procedimiento para la revisión de aseguramiento de la calidad.• Brinda técnicas y herramientas a los desarrolladores para producir productos de mayor calidad.• Reduce considerablemente el tiempo total de testing.• Los productos obtenidos son de mayor calidad.• Permite detectar y solucionar problemas cuando es menos costoso resolverlo.• Se mejora la comunicación dentro del equipo.• Hay una gestión adecuada de los riesgos y problemas de los proyectos.• Hay una adecuada gestión de cambios del proyecto.• Los miembros del equipo tienen claro los pasos a seguir.• Cada lección aprendida es registrada debidamente.• Se dispone de un procedimiento para realizar mediciones.• Sugiere utilizar las plantillas creadas para cumplir cada proceso definido.



Desventajas de Usar el Modelo

• El esfuerzo gastado en el aprendizaje de las técnicas y herramientas al inicio es costoso.

• Es difícil encontrar una medida del tamaño del producto desarrollado. Para la aplicación del modelo se ha utilizado la cantidad de líneas de código fuente como unidad de medida, pero que en sí tiene algunas desventajas.



Conclusiones y Recomendaciones

7



Conclusiones

Las estimaciones de tiempos, costos y tamaño de productos son más acertadas con las técnicas que se proponen.

Se desarrollan productos que están más ajustados a lo que el usuario requiere.

La trazabilidad direccional exigida en el modelo, junto a la buena documentación permitió facilitar las labores de mantenimiento de los productos desarrollados.

El control y monitoreo constante permitió encaminar los proyectos cuando hubo distorsiones con respecto a lo planificado.

El control de trabajo diario orienta al equipo a cumplir los objetivos de la iteración.Los desarrolladores cuentan con técnicas y herramientas para desarrollar con mayor calidad. La productividad de los desarrolladores se incrementa gradualmente.



ConclusionesAl aplicar el modelo en la empresa, el tiempo en testing disminuyó de un 40% a un 25% en promedio, estos porcentajes son con respecto al total del tiempo.

La densidad de defectos se reduce tremendamente al contar con técnicas de identificación y remoción de defectos.

También se ha notado que hay una mejor comunicación entre los miembros del equipo de desarrollo, esto gracias a las constantes reuniones que se dan en cada iteración donde se pueden identificar riesgos y problemas.

Existe un control adecuado de la integridad de los entregables.

El uso del enfoque ágil del modelo, permite detectar y solucionar problemas a tiempo.

Existe un adecuado tratamiento de las lecciones aprendidas.

Se monitorea con cierta frecuencia el cumplimiento del uso de los procesos con las revisiones de aseguramiento de la calidad.



RecomendacionesEl equipo deberá definir la duración de cada iteración

Es recomendable utilizar alguna herramienta que automatice la gestión de la configuración

Se recomienda utilizar un TaskBoard

El modelo debería estar expuesto en una intranet

Se recomienda utilizar alguna herramienta para gestionar los requerimientos

Iniciar estimación de PCU y luego la estimación PROBE

El equipo de QA debe ser externo al equipo del proyecto

Se recomienda utilizar alguna herramienta para automatizar las tareas del PSP

El líder usuario debe tener conocimientos del negocio como informáticos

El Scrum Master debe tener el poder necesario para permitir al equipo trabajar con normalidad

Muchas Gracias…

aplicación del modelo cmmi nivel 2, scrum y psp para el desarrollo de software presentado por:...

Documents