Para optar por el título de Ingeniero de Sistemas

Presentación del tema: "Para optar por el título de Ingeniero de Sistemas"— Transcripción de la presentación:

1 Para optar por el título de Ingeniero de Sistemas
Aplicación del Modelo CMMI nivel 2, SCRUM y PSP para el desarrollo de Software TESIS Para optar por el título de Ingeniero de Sistemas Presentado por: Raúl Castro Castillo Universidad Nacional de Ingeniería, Facultad de Ingeniería Industrial y de Sistemas

2 Contenido Introducción Definición de Problemas y Objetivos
Marco Teórico Obtención del Modelo Integrado Aplicación del Modelo Análisis de Resultados Conclusiones y Recomendaciones

3 Introducción 1

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

5 ¿Que necesitaba realmente el usuario?

6 Resumen de la Tesis El problema, objetivos e hipótesis
Obtención del Modelo Integrado Aplicación del Modelo Validación de la hipótesis

7 Definición del Problema y Objetivos
2

8 Definición del Problema
Entrega de productos de software de mala calidad, con cronogramas retrasados, con costos que exceden los presupuestos. Cambios Excesivos Cronogramas vencidos Mala Calidad Entrega de productos de software de mala calidad, con cronogramas retrasados, con costos que exceden los presupuestos, con requerimientos mal desarrollados que en la mayoría de casos no son aceptados ni usados por los clientes lo que genera pérdida de confianza a la empresa y por consiguiente pérdida de clientes. Presupuestos Irreales Trabajo Excesivo Retrabajo Comunicación Pobre

9 Incrementar la productividad de los desarrolladores
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 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 y herramientas para realizar estimaciones de tiempos y esfuerzos más exactas. Disminuir el tiempo de pruebas

10 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.”

11 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,

12 Marco Teórico 3

13 Marco Teórico CMMI SCRUM PSP PMBOK Métrica V3

14 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. Nacido en el Software Engineering Institute perteneciente a la Carnegie Mellon University.

15 CMMI Niveles de Madurez
Nivel 1. La organización en este nivel no dispone de un ambiente estable para el desarrollo y mantenimiento de productos y servicios. Nivel 2. En la organización que se encuentra en este nivel algunas áreas organizacionales y/o proyectos han alcanzado las metas genéricas y específicas establecidas en sus áreas de proceso, es decir planean sus procesos, los ejecutan, los miden y los controlan. Nivel 3. Tienen los procesos caracterizados, entendidos por los ejecutores, descritos mediante estándares, procedimientos, métodos y herramientas. Nivel 4. La organización selecciona y administra las actividades que contribuyen perceptiblemente al funcionamiento de proceso total. Estas actividades seleccionadas son controladas con técnicas estadísticas y otras técnicas cuantitativas. Nivel 5. Los procesos de la organización son mejorados continuamente basados en una comprensión cuantitativa de las causas comunes de variación inherentes a los procesos. El nivel 5 está centrado en mejorar continuamente el desempeño de los procesos con mejoras tecnológicas incrementales e innovadoras.

16 Áreas de Proceso

17 CMMI Arquitectura del Modelo
Áreas de Proceso Metas genéricas Metas específicas Prácticas genéricas Prácticas específicas Sub prácticas Los objetivos y prácticas genéricas tienen que ver con el grado de institucionalización de los procesos Los objetivos y prácticas específicas están vinculados a un área de proceso determinada. Son considerados elementos que deben ser satisfechos para implementar exitosamente los procesos relacionados con un área de proceso en particular.

18 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. Prefiere el conocimiento tácito de las personas al explícito de los procesos

19 Contenido de SCRUM

20 Involucrado versus Comprometido
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 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

21 El flujo de SCRUM

22 La comunicación en SCRUM
Reunión diaria Revisión del sprint Reunión retrospectiva

23 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.

24 En que nos ayuda PSP Planes 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

25 PSP Niveles

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

27 PSP El proceso

28 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. Identificar significa que provee una vista general en oposición a una descripción exhaustiva. Generalmente aceptado significa que los conocimientos y las prácticas, son aplicables a la mayoría de proyectos la mayoría de las veces. Buena práctica significa que hay un amplio acuerdo de que la aplicación correcta de las herramientas, habilidades y técnicas aumenta la posibilidad de tener existo.

29 PMBOK Procesos Iniciación Planificación Ejecución Control Cierre
Gestión de integración Acta proyecto Enunciado preliminar de alcance Desarrollo plan proyecto Ejecución plan proyecto Supervisa y controlar el trabajo Control global cambios Cierre de proyecto Gestión de la configuración Gestión del alcance Recopilar requisitos Definición alcance Creación EDT Verificación alcance Control cambio alcance Gestión del tiempo Definición actividades Secuenciación actividades Estimación de recursos Estimación duración actividades Desarrollo programación Control programación Gestión de costos Estimación costos Presupuesto costos Control de costos Gestión de la calidad Planificación calidad Garantía calidad Control calidad Gestión de RRHH Planificación organizativa Incorporación personal Desarrollo de equipo Gestión de equipo Gestión de la comunicación Identificar interesados Planificación comunicaciones Distribución información Gestionar a los interesados Reporte rendimiento Gestión de riesgos Planeación de riesgos Identificación riesgos Análisis cualitativo Análisis cuantitativo Planes de respuestas Control medidas Gestión de compras Planificación compras Planificación contratación Solicitar respuestas Gestión proveedores Efectuar adquisiciones Administrar contratos Cierre contratos Procesos con cambio de nombre Procesos originales Procesos eliminados Procesos nuevos

30 Métrica 3 Mé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 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. 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

31 Métrica v3 - Estructura

32 Obtención del Modelo Integrado
4

33 Definición de Requerimientos Lanzamiento del Proyecto
Esquema General Ingeniería de Requerimientos Definición de Requerimientos Gestión de Requerimientos Project Managment Lanzamiento del Proyecto Gestión del Proyecto Ingeniería de Software Desarrollo de actividades del Proyecto N Iteraciones

34 Definición de Requerimientos Lanzamiento del Proyecto
Esquema General Definición de Requerimientos Gestión de Requerimientos CMMI SCRUM Lanzamiento del Proyecto Gestión del Proyecto PMBOK PSP Desarrollo de actividades del Proyecto MÉTRICA 3 N Iteraciones

35 Los Elementos del Modelo
Estructura del Modelo Los Elementos del Modelo Políticas Procesos Artefactos Estructura de Roles Supuestos del Modelo

36 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.

37 Estructura de Roles

38 Definición de Políticas
Polí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

39 Mapa de Procesos

40 Definición de Procesos

41 Definición de Artefactos

42 Mapeo de Procesos y Entregables

43 Aplicación del Modelo Integrado
5

44 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

45 Testing y Documentadores
Presentación del Área 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). 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

46 Selección de Proyectos
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. Nombre del Proyecto Utilizó el Modelo Valoración de Empresa Si Extranet Crosland Sistema de Presupuestos No Sistema de Punto de Venta Sistema de Gestión Comercial

47 Análisis de Resultados
6

48 Tiempos Estimados Vs Tiempo Reales
Recopilación de Datos Tiempos Estimados Vs Tiempo Reales Proyecto Tiempo Estimado Tiempos Reales Gestión Comercial 6 13 Sistema de Presupuestos 11 Valoración de Empresas 8 Sistema de Puntos de Venta 5 7 Extranet Crosland 9

49 Análisis de Datos

50 Costos Estimados Vs Tiempo Reales
Recopilación de Datos Costos Estimados Vs Tiempo Reales Proyecto Costo Estimado Costos Reales Gestión Comercial 70000 120000 Sistema de Presupuestos 65000 105000 Valoración de Empresas 80000 100000 Sistema de Puntos de Venta 75000 800000 Extranet Crosland 85000 900000

51 Análisis de Datos

52 Alcance Estimado VS Alcance Real
Recopilación de Datos 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

53 Análisis de Datos

54 Número de RQM desarrollados correctamente
Recopilación de Datos Número de RQM desarrollados correctamente Proyecto Total de RQM RQM Aceptados Gestión Comercial 24 10 Sistema de Presupuestos 28 12 Valoración de Empresas 30 25 Sistema de Puntos de Venta 20 Extranet Crosland 22

55 Análisis de Datos

56 Recopilación de Datos Densidad de Defectos de los productos en Producción Proyecto Total de Funcionalidades Total de defectos Gestión Comercial 46 20 Sistema de Presupuestos 30 15 Valoración de Empresas 50 Sistema de Puntos de Venta 35 8 Extranet Crosland 70 12

57 Análisis de Datos

58 Tiempo de testing con respecto al tiempo total de desarrollo
Recopilación de Datos Tiempo de testing con respecto al tiempo total de desarrollo Proyecto Tiempo Total Total en Testing Gestión Comercial 13 5 Sistema de Presupuestos 11 4 Valoración de Empresas 8 2 Sistema de Puntos de Venta 7 1 Extranet Crosland 9

59 Análisis de Datos

60 Recopilación de Datos Número de defectos encontrados antes de la fase de testing Proyecto Total de defectos hasta la fase de testing Total de defectos encontrados antes de testing Gestión Comercial 56 Sistema de Presupuestos 75 Valoración de Empresas 40 20 Sistema de Puntos de Venta 30 18 Extranet Crosland 35

61 Análisis de Datos

62 Recopilación de Datos Productividad de los Desarrolladores Proyecto
Gestión Comercial No se controla productividad Sistema de Presupuestos Valoración de Empresas 20 líneas de código fuente por minuto Sistema de Puntos de Venta 30 líneas de código fuente por minuto. Extranet Crosland 50 líneas de código fuente por minuto.

63 Yield de los Desarrolladores
Recopilación de Datos Yield de los Desarrolladores Proyecto Yield Promedio Valorización de Empresas 0% Extranet Crosland Sistema de Presupuestos 20% Sistema de Puntos de Venta 25% Gestión Comercial 30%

64 Análisis de Datos

65 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.

66 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.

67 Conclusiones y Recomendaciones
7

68 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.

69 Conclusiones Al 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.

70 Recomendaciones El 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

71 Muchas Gracias…