MEJORAMIENTO DEL PROCESO DE SOFTWARE (MPS) ¿Qué es MPS ? implica muchas cosas. Primero, que los elementos de un proceso de software efectivo pueden definirse.

Presentación del tema: "MEJORAMIENTO DEL PROCESO DE SOFTWARE (MPS) ¿Qué es MPS ? implica muchas cosas. Primero, que los elementos de un proceso de software efectivo pueden definirse."— Transcripción de la presentación:

1 MEJORAMIENTO DEL PROCESO DE SOFTWARE (MPS) ¿Qué es MPS ? implica muchas cosas. Primero, que los elementos de un proceso de software efectivo pueden definirse en forma efectiva; segundo, que un enfoque organizacional existente sobre el desarrollo del software puede valorarse en contraste con dichos elementos; y tercero, que es posible definir una estrategia de mejoramiento significativa. La estrategia MPS transforma el enfoque existente sobre el desarrollo del software en algo que es más enfocado, más repetible y más confiable (en términos de la calidad del producto producido y de la oportunidad de la entrega).

2 Enfoques del MPS Certificadores de calidad. Los esfuerzos de mejoramiento de proceso que impulsa este grupo se enfocan en la siguiente relación: Su enfoque consiste en enfatizar los métodos de valoración y examinar un conjunto bien definido de características que le permiten determinar si el proceso muestra calidad. Formalistas. Este grupo quiere entender (y cuando es posible, optimizar) el flujo de trabajo del proceso. Para lograrlo, usa lenguajes de modelado de proceso (PML) a fin de crear un modelo del proceso existente y luego diseñar extensiones o modificaciones que harán más efectivo el proceso. Defensores de las herramientas. Este grupo insiste en un enfoque del MPS asistido por herramientas que modelan el flujo de trabajo y otras características del proceso de manera que pueda analizarse para su mejoramiento.

3 Reformadores. La meta de este grupo es el cambio organizacional que pueda conducir a un mejor proceso de software. Tienden a enfocarse más en los temas humanos y enfatizan medidas de capacidad humana y estructura Ideólogos. Este grupo se enfoca en lo adecuado de un modelo de proceso particular para un dominio de aplicación específico o estructura organizativa. En lugar de los modelos de proceso de software típicos (por ejemplo, modelos iterativos), los ideólogos tendrían mayor interés en un proceso que, por ejemplo, apoyara el reuso o la reingeniería. Profesionales. Este grupo usa un enfoque pragmático, “que enfatiza la administración tradicional de proyecto, calidad y producto, y aplica planificación y métricas en el nivel de proyecto, pero con poco modelado de proceso formal o pronunciamiento de apoyo”

4 Modelos de madures Un modelo de madurez se aplica dentro del contexto de un marco conceptual MPS. La intención del modelo de madurez es proporcionar un indicio global de la “madurez del proceso” que muestra una organización de software, es decir, un indicio de la calidad del proceso de software, el grado en el que los profesionales entienden y aplican el proceso, y el estado general de la práctica de ingeniería del software. Esto se logra usando algún tipo de escala ordinal. madurez de capacidad Nivel 5, optimizado. La organización tiene sistemas de realimentación cuantitativa en su lugar para identificar las debilidades del proceso y fortalecer esos puntos de manera proactiva. Los equipos de proyecto analizan defectos para determinar sus causas; los procesos de software se evalúan y actualizan para evitar que recurran tipos conocidos de defectos. Nivel 4, gestionado. Métricas de proceso de software y de calidad de producto detalladas establecen el cimiento de evaluación cuantitativa. Las variaciones significativas en el desempeño del proceso pueden distinguirse del ruido aleatorio, y pueden predecirse las tendencias en las cualidades del proceso y el producto.

5 Nivel 3, definido. Los procesos para administración e ingeniería se documentan, estandarizan e integran en un proceso de software estándar para la organización. Todos los proyectos usan una versión aprobada y a la medida del proceso de software estándar de la organización para desarrollo de software. Nivel 2, repetible. Se establecen procesos de administración de proyecto básicos para rastrear costo, calendario y funcionalidad. La planificación y administración de nuevos productos se basa en la experiencia con proyectos similares. Nivel 1, inicial. Pocos procesos definidos, y el éxito depende más del esfuerzo heroico individual que de seguir un proceso y usar un esfuerzo sinérgico de equipo.

6 Modelo de madurez CMM indica que muchas organizaciones muestran niveles de “inmadurez de proceso” que minan cualquier intento racional por mejorar las prácticas de ingeniería de software Nivel 0, negligente. Fracaso para permitir que tenga éxito un proceso de desarrollo exitoso. Todos los problemas se perciben como problemas técnicos. Las actividades administrativas y de aseguramiento de la calidad están condenadas a situarse por encima y ser superfluas en relación con las tareas del proceso de desarrollo del software. Se confía en las balas de plata. Nivel 1, obstructivo. Se imponen procesos contraproducentes. Los procesos se definen rígidamente y se adhieren a la forma que subrayan. Abundan las ceremonias rituales. La administración colectiva impide la asignación de responsabilidad. Status quo über alles (sobre todo). Nivel 2, despreciador. No se preocupa por la buena ingeniería de software institucionalizada. Hay desunión completa entre actividades de desarrollo de software y actividades de mejoramiento del proceso de software y falta completa de programas de capacitación. Nivel 3, socavación. Desprecio total por la propia organización, descrédito consciente de los esfuerzos de mejoramiento del proceso de software de los pares de la organización. Recompensa al fracaso y al pobre desempeño

7 ¿ El MPS es para todos? Existen sustanciales diferencias culturales entre grandes y pequeñas organizaciones de desarrollo de software. No debe sorprender que las organizaciones pequeñas sean más informales, apliquen menos prácticas estándar y tiendan a la autoorganización. También tienden a enorgullecerse por la “creatividad” de los miembros individuales de la organización de software, e inicialmente ven un marco conceptual MPS como excesivamente burocrático y pesado. Sin embargo, el mejoramiento de los procesos es tan importante para una organización pequeña como para una grande. Dentro de las organizaciones pequeñas, la implementación de un marco conceptual MPS requiere recursos que pueden tener un suministro reducido. Los administradores deben asignar personal y dinero para lograr que ocurra la ingeniería del software. Por tanto, sin importar el tamaño de la organización del software, es razonable considerar la motivación empresarial para el MPS.

8 EL PROCESO MPS Valoración y análisis de la desviación La valoración examina un amplio rango de acciones y tareas que conducirán a un proceso de alta calidad. Por ejemplo, sin importar el modelo de proceso que elija, la organización de software debe establecer mecanismos genéricos como: enfoques definidos para comunicación con el cliente; establecimiento de métodos para representar requisitos de usuarios y muchas otras. Educación y capacitación: un elemento clave de cualquier estrategia MPS es la educación. Con ese fin, deben realizarse tres tipos de educación y capacitación: Conceptos y métodos genéricos. Dirigida tanto a gerentes como a profesionales. Tecnología y herramientas específicas. Dirigida principalmente a profesionales. Comunicación empresarial y temas relacionados con la calidad. Dirigida a todos los participantes. Selección y justificación Una vez completada la actividad de valoración inicial4 e iniciada la educación, una organización de software debe comenzar a elegir. Primero, debe elegir el modelo de proceso (capítulos 2 y 3) que se ajuste mejor a su organización, a sus participantes y al software que construirá. Una vez hecha la elección, deben emplearse tiempo y dinero para demostrarla dentro de una organización, y dichos gastos de recursos deben justificarse

9 Instalación/migración: La instalación es el primer punto donde una organización de software siente los efectos de los cambios implementados como consecuencia del mapa de caminos MPS. Instalación y migración en realidad son actividades de rediseño de proceso de software (RPS). Evaluación: Aunque se menciona como la última actividad en el mapa de caminos MPS, la evaluación ocurre a lo largo del MPS. La actividad de evaluación valora el grado en el cual los cambios se demostraron y adoptaron Gestión del riesgo para MPS: El MPS es una empresa riesgosa. De hecho, más de la mitad de todos los esfuerzos MPS terminan en fracaso. Las razones del fracaso varían enormemente y son específicas de la organización. Entre los riesgos más comunes están: falta de apoyo administrativo, resistencia cultural por parte del personal técnico, una estrategia MPS pobremente planeada, un enfoque excesivamente formal del MPS, selección de un proceso inadecuado, entre muchos otros factores.

10 Factores de éxito cruciales: Compromiso y apoyo de la administración: El MPS triunfará sólo si la administración se involucra de manera activa. Los gerentes ejecutivos deben reconocer la importancia del software para sus compañías y ser patrocinadores activos del esfuerzo MPS. Involucramiento del personal: El mejoramiento debe ser orgánico, patrocinado por gerentes técnicos y técnicos ejecutivos, y adoptado por profesionales locales. Integración y comprensión del proceso: El proceso de software no existe en un vacío organizativo. Debe integrarse con otros procesos y requisitos empresariales Una estrategia MPS a la medida: No hay una receta para la estrategia MPS. Para una buena estrategia MPS deben considerarse cultura de equipo, mezcla de producto, y fortalezas y debilidades locales. Administración sólida del proyecto MPS: El MPS es un proyecto como cualquier otro. Involucra coordinación, calendarización y muchas cosas mas. Sin administración activa y efectiva, un proyecto MPS está condenado al fracaso

11 CMMI El CMMI representa un metamodelo de proceso en dos formas diferentes: 1) como un modelo “continuo” y 2) como un modelo “en etapas”. El metamodelo CMMI continuo describe un proceso en dos dimensiones. Cada área de proceso (por ejemplo, planificación de proyecto o gestión de requisitos) se valora formalmente contra metas y prácticas específicas y se clasifica de acuerdo con los siguientes niveles de capacidad: Nivel 0: Incompleto: el área del proceso (por ejemplo, gestión de requisitos) no se realiza o no logra todas las metas y objetivos definidos por la CMMI para la capacidad nivel 1 del área de proceso. Nivel 1: Realizado: todas las metas específicas del área de proceso (como se define mediante la CMMI) están satisfechas. Nivel 2: Administrado: se satisfacen todos los criterios del nivel 1 de capacidad. Además, todo el trabajo asociado con el área de proceso se encuentra acorde con una política definida de manera organizacional. Nivel 3: Definido: se logran todos los criterios del nivel 2 de capacidad. Además, el proceso se “hace a la medida, a partir del conjunto de procesos estándar y de acuerdo con los lineamientos de producción de la organización Nivel 5: Optimizado: se logran todos los criterios del nivel 4 de capacidad. Además, el área de proceso se adapta y optimiza

12 La CMMI define cada área de proceso en términos de “metas específicas”, y de “prácticas específicas” requeridas para lograr dichas metas. Las metas específicas establecen las características que deben existir si las actividades implicadas por un área de proceso han de ser efectivas. Las prácticas específicas desglosan una meta en un conjunto de actividades relacionadas con el proceso. Las metas específicas (ME) y las prácticas específicas (PE) asociadas definidas para planificación de proyecto son : Establecimiento de estimaciones Desarrollo de un plan de proyecto Obtención de compromiso del plan Además de las metas y prácticas específicas, la CMMI también define un conjunto de cinco metas genéricas y prácticas relacionadas para cada área de proceso. Las metas genéricas (MG) y las prácticas genéricas (PG) para el área de proceso planificación del proyecto son: 1. Logro de metas específicas 2. Institucionalización de un proceso administrado 3. Institucionalización de un proceso definido 4. Institucionalización de un proceso administrado cuantitativamente 5. Institucionalización de un proceso de optimización

13 El CMM personal Como el CMM, la CMMI y los marcos conceptuales MPS relacionados, el CMM de personal define un conjunto de cinco niveles de madurez organizativa que proporcionan un indicio de la sofisticación relativa de las prácticas y procesos de la fuerza laboral. Dichos niveles de madurez se ligan a la existencia (dentro de una organización) de un conjunto de áreas de proceso clave (APC). El CMM de personal complementa cualquier marco conceptual MPS al alentar a una organización a nutrir y mejorar su activo más importante: su personal. Tan importante, que establece una atmósfera de fuerza de trabajo que permite a una organización de software “atraer, desarrollar y conservar talento sobresaliente”

14 OTROS MARCOS CONCEPTUALES MPS Aunque los CMM y CMMI del SEI son los marcos conceptuales MPS de mayor aplicación, se han propuesto algunas alternativas7 que están en uso. Entre las más ampliamente utilizadas se encuentran: SPICE: una iniciativa internacional para dar apoyo a la valoración de proceso ISO y a estándares de proceso de ciclo de vida [SPI99] ISO/IEC 15504 para Valoración de Proceso Bootstrap: un marco conceptual MPS para organizaciones pequeñas y medianas que se adecua a SPICE [Boo06] PSP y TSP: marcos conceptuales MPS individuales y específicos de equipo ([Hum97], [Hum00]) que se enfocan en procesos micro, un enfoque más riguroso del desarrollo de software acoplado con medición TickIT: método de auditoría [Tic05] que valora el cumplimiento de una organización al Estándar ISO 9001:2000

15

16 Tendencias MPS Para ser efectivo en el mundo de desarrollo del software del siglo XXI, los futuros marcos conceptuales MPS deben volverse significativamente más ágiles. En lugar de un enfoque centrado en la organización (que puede tardar años en completarse exitosamente), los esfuerzos MPS contemporáneos deben enfocarse en el nivel del proyecto y trabajar para mejorar un proceso de equipo en semanas, no meses ni años. Para lograr resultados significativos (incluso en el nivel del proyecto) en un tiempo corto, los modelos de marco conceptual complejos pueden dar lugar a modelos más simples.