Cmm2

173 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
173
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cmm2

  1. 1. Capítulo 2: La Estructura Base de la Madurez del Proceso de Software La mejora continua del proceso está basada en muchos pasos pequeños de evolución más que en innovaciones revolucionarias. El CMM proporciona una estructura base para organizar estos pasos de evolución en cinco niveles de madurez que colocan bases sucesivas para una mejora continua del proceso. Estos cinco niveles de madurez definen una escala ordinal para medir la madurez del proceso de software de una organización y para evaluar su capacidad de proceso de software. También le ayudan a una organización a priorizar sus esfuerzos de mejora. Un nivel de madurez es una base evolucionaria bien definida hacia el logro de un proceso de software maduro. Cada nivel de madurez comprende un conjunto de objetivos del proceso que, cuando se logran, estabilizan un componente importante del proceso de software. El logro de cada nivel de la estructura de madurez establece un componente diferente en el proceso del software, resultando en un aumento en la capacidad para procesos de la organización. La organización del CMM en los cinco niveles que se muestran en la Fig. 2.1 le da prioridad a las acciones de mejora para aumentar la madurez del proceso del software. Las flechas etiquetadas indican el tipo de capacidad de proceso que se está institucionalizando por la organización en cada nivel de la estructura de madurez. Los cinco niveles pueden describirse brevemente como: 1. Inicial El proceso de software está caracterizado como ad hoc, y ocasionalmente incluso caótico. Hay pocos procesos definidos, y el éxito depende de esfuerzos individuales y heroicos. 2. Repetible Los procesos básicos de administración del proyecto están establecidos para controlar el costo, los tiempos y la funcionalidad. Está en lugar la disciplina necesaria del proceso para repetir éxitos anteriores sobre proyectos con aplicaciones similares. 3. Definido El proceso de software está documentado, estandarizado e integrado en un proceso de software estándar para la organización tanto para las actividades de administración como para las de ingeniería. Todos los proyectos usan una versión aprobada y hecha a medida del proceso de software estándar de la organización para desarrollar y mantener el software. 4. Administrado Se juntan medidas detalladas del proceso del software y de la calidad del producto. Tanto el proceso del software como los productos se controlan y comprenden cuantitativamente. 5. Optimizante Se hace posible un proceso de mejoras continuas gracias al feedback cuantitativo desde el proceso y a partir de ideas y tecnologías innovadoras. Estos cinco niveles reflejan el hecho de que el CMM es un modelo para mejorar la capacidad de las organizaciones de software. Las prioridades en el CMM, según se expresa con estos niveles, no están dirigidas a proyectos individuales. Un proyecto problemático bien podría darle prioridad a sus problemas en una forma diferente de la taxonomía dada por el CMM. Sus soluciones pueden ser de un valor limitado para el resto de la organización porque otros proyectos pueden tener diferentes problemas o no poder sacar ventaja de sus soluciones porque carecen de las bases necesarias para implementar las soluciones. El CMM se enfoca en procesos que son de valor en toda la organización. 1
  2. 2. 2.1 Caracterización del Comportamiento de los Niveles de Madurez Los niveles de madurez del 2 al 5 pueden caracterizarse a través de las actividades realizadas por la organización para establecer o mejorar el proceso de software, por las actividades realizadas en cada proyecto, y por la capacidad de proceso resultante en todos los proyectos. 2.1.1 Nivel 1: El Nivel Inicial En el Nivel Inicial, la organización típicamente no proporciona un ambiente estable para desarrollar y mantener el software. El sobre-compromiso es una característica de las organizaciones del Nivel 1, las que frecuentemente tienen dificultades en asumir compromisos que el personal pueda cumplir con un proceso de ingeniería ordenado, resultando en una serie de crisis. Durante una crisis, los proyectos típicamente abandonan los procedimientos planeados y se revierten a la codificación y al testeo. El éxito depende de tener un manager excepcional y un equipo de software efectivo y fogueado. Ocasionalmente, managers de software capaces y fuertes logran soportar las presiones para tomar atajos en el proceso del software; pero cuando ellos abandonan el proyecto su influencia estabilizadora se va con ellos. Incluso un proceso fuerte de ingeniería no puede superar la inestabilidad creada por la ausencia de prácticas de administración sensatas. A pesar de este proceso ad-hoc, incluso caótico, las organizaciones de Nivel 1 frecuentemente desarrollan productos que funcionan, aunque pueden excederse en presupuesto y en tiempo. El éxito en las organizaciones de Nivel 1 depende de la competencia y del heroísmo de la gente de la organización1 y no puede repetirse a menos que los mismos individuos competentes sean asignados al siguiente proyecto. De esta manera, en el Nivel 1, la capacidad es una característica de los individuos, no de la organización. 2.1.2 Nivel 2: El Nivel Repetible En el Nivel Repetible, están establecidas las políticas para administrar un proyecto de software y los procedimientos para aplicar estas políticas. El planeamiento y la administración de nuevos proyectos se basa en la experiencia con proyectos similares. La capacidad del proceso se ve mejorada por el establecimiento de una disciplina de administración del proceso básico sobre una base de proyecto a proyecto. Los proyectos implementan procesos efectivos que están definidos, documentados, practicados, entrenados, medidos, aplicados, y mejorables. Los proyectos en las organizaciones de Nivel 2 tienen controles básicos de administración de software instalados. Se hacen compromisos realistas de proyectos, en base a los resultados observados en proyectos previos y en los requerimientos del proyecto actual. Los administradores del software para un proyecto rastrean los costos, tiempos y funcionalidad del software; los problemas para cumplir los compromisos se identifican a medida que surgen. Los requerimientos de software y los productos desarrollados para satisfacerlos son de línea base, y su integridad está controlada. Los estándares del proyecto de software están definidos, y la organización asegura que se siguen fielmente. El proyecto de software funciona con sus subcontratistas, si los hay, para establecer una relación cliente-proveedor efectiva. 1 L a selección, contratación, desarrollo y retención de gente competente son temas de importancia en todos los niveles de madurez, pero están en gran medida fuera del alcance del CMM. 2
  3. 3. Los procesos de una organización de Nivel 2 pueden diferir entre proyectos. El requerimiento organizacional para lograr el Nivel 2 es que haya políticas a nivel de organización que guíen a los proyectos en el establecimiento del proceso de administración adecuado. La capacidad de proceso de software de las organizaciones de Nivel 2 puede resumirse como disciplinada porque el planeamiento y el seguimiento del proyecto de software es estable y pueden repetirse los éxitos anteriores. El proceso del proyecto está bajo el control efectivo de un sistema de administración de proyectos, siguiendo planes realistas basados en la performance de proyectos previos 2.1.3 Nivel 3: El Nivel Definido En el Nivel Definido hay un proceso (o procesos) estándar documentado para desarrollar y mantener el software, y se usa a través de la organización. Conocido dentro de CMM como el proceso de software estándar de la organización, este proceso estándar incluye tanto ingeniería de software como procesos de administración y los integra en un todo coherente. Los procesos establecidos en el Nivel 3 se usan (y se cambian, según sea apropiado) para ayudar a los administradores de software y al personal técnico a desempeñarse más efectivamente. La organización aprovecha las prácticas de ingeniería de software efectivas al estandarizar su proceso de software. Se le asigna la responsabilidad de las actividades del proceso de software un grupo dentro de la organización (por ejemplo, un grupo de proceso de ingeniería de software o SEPG [Fowler90]). Se implementa un programa de entrenamiento en toda la organización para asegurarse que el personal y los administradores tengan el conocimiento y la capacitación requeridos para cumplir con sus roles asignados. Los proyectos ajustan el proceso de software estándar de la organización para desarrollar sus propios procesos de software definidos, lo que explica las características únicas del proyecto. El proceso adecuado al proyecto se conoce en CMM como proceso de software definido del proyecto. Es el proceso usado en desarrollar las actividades del proceso. Un proceso de software definido contiene un conjunto coherente e integrado de procesos de administración e ingeniería de software bien definido. Un proceso bien definido puede caracterizarse como incluyendo criterios de prontitud, entradas, estándares y procedimientos para realizar el trabajo, mecanismos de verificación (como ser revisiones de los pares), salidas, y criterios de terminación. Como el proceso de software está bien definido, la administración tiene un buen conocimiento en el progreso técnico sobre el proceso. La capacidad del proceso de software de las organizaciones de Nivel 3 pueden resumirse como estándares y consistentes porque tanto la ingeniería de software como las actividades de administración son estables y repetibles. Dentro de líneas de productos establecidas, el costo, los plazos, y la funcionalidad están bajo control, y se sigue la calidad del software. Esta capacidad de proceso está basada en una comprensión común y generalizada de las actividades, roles y responsabilidades en un proceso de software definido. 2.1.4 Nivel 4: El Nivel Administrado En el Proceso Administrado la organización establece objetivos de calidad cuantitativos tanto para los productos de software como para los procesos. Se miden la productividad y la calidad para las actividades de los procesos de software importantes en todos los proyectos como parte del programa de mediciones de la organización. Se usa una base de datos de los procesos de software de toda la organización para recolectar y analizar los datos disponibles de los procesos de software definidos de los proyectos. Los 3
  4. 4. procesos de software se instrumentan con mediciones bien definidas y consistentes. Estas mediciones establecen la fundación cuantitativa para evaluar los procesos de software de los proyectos y los productos. Los proyectos logran un control sobre sus productos y procesos disminuyendo la variación en la performance de sus procesos para caer dentro de límites cuantitativos aceptables. Pueden distinguirse las variaciones significativas en la performance del proceso de la variación al azar (ruido), particularmente dentro de líneas de productos establecidas. Se conocen y se manejan cuidadosamente los riesgos involucrados en elevar la curva de aprendizaje de un nuevo dominio de aplicación. La capacidad de proceso de software de las organizaciones de Nivel 4 puede resumirse como cuantificable y predecible porque el proceso está medido y funciona dentro de límites cuantitativos. Este nivel de capacidad de proceso le permite a una organización predecir tendencias en calidad de productos y procesos dentro de los límites cuantitativos existentes. Como el proceso es a la vez estable y medido, cuando ocurre alguna circunstancia excepcional, puede identificarse y tratarse la “causa especial” de la variación. Cuando se exceden los límites predefinidos, se toman acciones para comprender y corregir la situación. Los productos de software son de una alta calidad predecible. 2.1.5 Nivel 5: El Nivel Optimizante En el Nivel Optimizante toda la organización está enfocada en una mejora continua del proceso. La organización tiene los medios para identificar debilidades y fortalecer el proceso en forma proactiva, con el objetivo de prevenir la ocurrencia de defectos. Los datos sobre la efectividad del proceso de software se usan para realizar análisis de costo / beneficio de nuevas tecnologías y cambios propuestos al proceso de software de la organización. Se identifican y transfieren a toda la organización las innovaciones que explotan las mejores prácticas de ingeniería del software. Los equipos de software en las organizaciones de nivel 5 analizan los defectos para determinar sus causas. Evalúan el proceso de software para evitar que vuelvan a ocurrir tipos conocidos de defectos y diseminan las lecciones aprendidas para toda la organización. El desperdicio crónico, en la forma de trabajo vuelto a hacer, puede encontrarse en cualquier sistema simplemente debido a la variación al azar. Los esfuerzos organizados para eliminar el desperdicio resultan en un cambio al sistema, o sea, en la mejora del proceso por medio del cambio de las “causas comunes” de ineficiencia para evitar que ocurra el desperdicio. Mientras que esto es verdad para todos los niveles de madurez, es el enfoque del Nivel 5. La capacidad del proceso de software de las organizaciones de Nivel 5 puede caracterizarse como de mejoras continuas porque las organizaciones de Nivel 5 continuamente luchan para mejorar el alcance de la capacidad de su proceso, mejorando así la performance del proceso de sus proyectos. las mejoras ocurren debido a avances incrementales en el proceso existente y a innovaciones usando nuevas tecnologías y métodos. La tecnología y las mejoras del proceso se planean y administran como actividades de negocios ordinarias. 2.2 Salteando los Niveles de Madurez El CMM identifica los niveles a través de los cuales una organización debería evolucionar para establecer una cultura de excelencia de ingeniería de software. Como 4
  5. 5. cada nivel de madurez en el CMM es una base necesaria sobre la que se construirá el siguiente nivel, tratar de saltearse niveles puede ser contraproductivo. Las organizaciones pueden instituir mejoras específicas al proceso en el momento que elijan, incluso antes de estar preparadas para avanzar al nivel en el que se recomienda la práctica específica. Sin embargo, las organizaciones deberían comprender que la estabilidad de estas mejoras corre un mayor riesgo porque las bases para la institucionalización exitosa no han sido completadas. Los procesos sin los fundamentos adecuados pueden fallar en cualquier punto en el que se los necesite - bajo presión. Por ejemplo, un proceso de software bien definido que es característico de una organización de Nivel 3 puede colocarse con un gran riesgo si las prácticas de administración del nivel 2 son deficientes. Por ejemplo, la administración puede preparar una agenda de compromisos pobremente planeada o no poder controlar los cambios a los requerimientos de línea base. En forma similar, muchas organizaciones recolectan datos detallados característicos del Nivel 4, sólo para encontrase con que los datos resultan ininterpretables debido a la inconsistencia en el proceso de desarrollo de software y las definiciones de medición. Al mismo tiempo, debe reconocerse que los esfuerzos para mejorar el proceso deberían enfocarse en las necesidades de la organización en el contexto de su ambiente de negocios y que prácticas de niveles superiores pueden ser útiles para las necesidades actuales de una organización o proyecto. Por ejemplo, a las organizaciones que quieren pasar del Nivel 1 al 2 frecuentemente se les dice que establezcan un grupo de proceso de ingeniería de software (SEPG), que es un atributo de las organizaciones de Nivel 3. Mientras que un SEPG no es una característica necesaria de una organización de nivel 2, puede ser una parte útil de la receta para lograr el Nivel 2. Esto a veces se describe como establecer un SEPG de Nivel 1 para llevar a la organización de Nivel 1 hasta un Nivel 2. Las actividades de mejora al proceso de software de Nivel 1 pueden depender principalmente de la lucidez y competencia del personal del SEPG hasta que haya una infraestructura para soportar mejoras más disciplinadas y abarcativas. Otro ejemplo es el proceso de construcción del software. Ciertamente esperaríamos que las organizaciones de Nivel 1 realizaran un análisis, diseño, codificación y prueba de los requerimientos. Sin embargo, estas actividades no se describen en el CMM hasta el nivel 3, en donde se describen como procesos de ingeniería coherentes y bien integrados. En forma similar, los procesos cambian al pasar del Nivel 1 al Nivel 2. La mejora de los procesos ocurre a medida que una organización asciende por los niveles de madurez. Sin embargo, la masterización del manejo de cambios continuos en el proceso es característica de las organizaciones del Nivel 5. Estas variaciones para implementar las mejoras al proceso del software son artefactos en la forma en que se definen las áreas de procesos claves. Un área de proceso clave describe un proceso completamente implementado e institucionalizado, uno que ha sido masterizado por una organización. Una organización de Nivel 1 podría implementar casi cualquier proceso descripto en el CMM, aunque tal vez de una manera incompleta o ad hoc. Por el simple hecho que una organización de Nivel 1 realice un proceso de una manera ad hoc, esto no debe desmerecer el hecho de que lo realiza. La confiabilidad y consistencia de este proceso puede y debe mejorarse. la capacidad de una organización puede germinar de la semilla de un proceso ad hoc. 5
  6. 6. 2.3 Visibilidad dentro del Proceso de Software Cada nivel del CMM aumenta la visibilidad dentro del proceso de software tanto para los managers como para el personal de ingeniería. Los ingenieros del software tienen una visión detallada del estado del proyecto porque tienen información de primera mano sobre el estado y performance del proyecto. Sin embargo, en proyectos más grandes, la visión que tienen del mismo normalmente se deriva sólo de su experiencia personal en su área de responsabilidad. Los que están fuera del proyecto sin una exposición al mismo de primera mano, como ser los senior manager, carecen de visibilidad en el proceso del proyecto y por lo tanto sólo se apoyan en revisiones periódicas para obtener la información que necesitan para monitorear el progreso. La Figura 2.2, creada por Jeff Perdue, ilustra el nivel de visibilidad en el estado y la performance del proyecto proporcionados al manager en cada nivel de madurez del proceso. En el Nivel 1, el proceso de software es una entidad amorfa - una caja negra - y la visibilidad del proceso del proyecto es limitada. Como la división en etapas de las actividades está pobremente definida, a los managers les cuesta mucho establecer el estado de las actividades y del progreso del proyecto.2 Los requerimientos fluyen en el proceso de software de una manera no controlada, y resulta un producto. El desarrollo del software es frecuentemente visto como magia negra, especialmente por los managers que no están familiarizados con el software. El cliente puede evaluar si el producto satisface los requerimientos sólo cuando se lo entregan. En el Nivel 2 se controlan los requerimientos del cliente y los productos de trabajo, y se han establecido prácticas básicas de administración del proyecto. Estos controles de administración permiten una visibilidad dentro del proyecto en ciertas ocasiones. El proceso de construir el software puede verse como una sucesión de cajas negras que permiten una visibilidad dentro del proyecto en los puntos de transición (fundamentos del proceso) a medida que la actividad fluye entre las cajas. Aunque la administración puede no conocer los detalles de lo que está pasando en la caja, se conocen y están identificados los productos del proceso y los puntos de verificación para confirmar que el proceso está funcionando. La administración reacciona a los problemas a medida que éstos ocurren. El cliente puede revisar el producto en puntos de verificación definidos durante el proceso de software. En el nivel 3 es visible la estructura interna de las cajas, o sea, las tareas en el proceso de software definido del proyecto. La estructura interna representa la forma en la que se ha aplicado el proceso de software estándar de la organización a proyectos específicos. Tanto los managers como los ingenieros comprenden sus roles y responsabilidades dentro del proceso y cómo sus actividades interactúan en el nivel de detalle apropiado. La administración se prepara proactivmente para riesgos que puedan surgir. El cliente puede obtener actualizaciones de estado rápidas y precisas porque los procesos definidos proporcionan una gran visibilidad dentro de las actividades del proyecto. En el Nivel 4, el proceso de software definido está cuantitativamente instrumentado y controlado. Los managers pueden medir el progreso y los problemas. Tienen una base objetiva y cuantitativa para la toma de decisiones. Su capacidad para predecir resultados se vuelve constantemente más precisa a medida que la variabilidad en el proceso disminuye. El cliente puede establecer una comprensión cuantitativa de la capacidad del proceso y del riesgo antes de que el proyecto comience. En el Nivel 5, se prueban continuamente nuevas formas mejoradas de construir 2 Esto conduce a la regla algo humorística de Noventa - Noventa: 90% del proyecto está completo el 90% del tiempo. 6
  7. 7. el software, de una manera controlada, para mejorar la productividad y la calidad. El cambio disciplinado es una forma de vida: cada vez que se identifican actividades ineficientes o propensas al error se reemplazan o revisan. Hay una visión clara que se extiende más allá de los procesos existentes y dentro de los efectos de cambios potenciales a los procesos. Los managers pueden estimar y luego rastrear cuantitativamente el impacto y la efectividad del cambio. El cliente y la organización de software siguen trabajando juntos para establecer una relación cliente - proveedor fuerte. En los cinco niveles, la capacidad del proceso interactúa con las personas, la tecnología y la medición a medida que una organización madura, como se ilustra en la Tabla 2.1. 2.4 Predicción de la Performance La madurez del proceso de software de una organización ayuda a predecir la capacidad de un proyecto de lograr sus objetivos. Los proyectos en las organizaciones de Nivel 1 experimentan amplias variaciones en lograr objetivos de costo, plazos, funcionalidad y calidad. La Figura 2.3 ilustra las clases de mejoras esperadas en predictabilidad, control y efectividad en la forma de densidad de probabilidad para la performance probable de un proyecto particular con respecto a objetivos, que pueden ser plazos, costo, calidad, etc. La primera mejora esperada a medida que una organización madura es en predictabilidad. A medida que la madurez aumenta, la diferencia entre los resultados deseados y los obtenidos disminuye a través de los proyectos. Por ejemplo, las organizaciones de Nivel 1 a menudo no cumplen con la fecha de entrega originalmente pactada por un amplio margen, mientras que las organizaciones de mayor nivel de madurez deberían poder cumplir las fechas previstas con una mayor precisión. La segunda mejora es en control. A medida que la madurez aumenta, la variabilidad de los resultados reales con respecto a los propuestos disminuye. Por ejemplo, en las organizaciones de Nivel 1 las fechas de entrega para proyectos de tamaño similar no son predecibles y varían grandemente de una a otra. Sin embargo, en organizaciones con niveles de madurez más altos, serán entregados dentro de un rango menor. La tercera mejora es en efectividad. Los resultados esperados mejoran a medida que la madurez de la organización aumenta. O sea, a medida que la organización de software madura, los costos disminuyen, el tiempo de desarrollo se acorta y la productividad y la calidad aumentan. En una organización de nivel 1, el tiempo de desarrollo puede ser bastante largo debido a la cantidad de trabajo que se hace dos veces para corregir errores [Cooper93]. En contraste, las organizaciones de niveles de maduración más altos tienen una efectividad de proceso aumentada y un trabajo hecho dos veces reducido, lo que resulta en un tiempo de desarrollo más corto. Como se ilustra en la Figura 2.4, se esperan las tres mejoras a medida que el proceso de software de la organización madura. Estas expectativas se basan en los resultados cuantitativos que las mejoras del proceso han logrado en otras industrias, y son consistentes con los resultados del estudio del caso inicial informados por las organizaciones de software [Dion93, Humphrey91b, Lipke92, Wohlwend93]. Nótese la interacción entre la predictabilidad y la efectividad a medida que una organización pasa del Nivel 1 al Nivel 2. Debido a la mejora en la estimación, los planes se vuelven más realistas, conduciendo a un planeamiento de plazos más largos. Al 7
  8. 8. mismo tiempo, debido a las mejoras en la realización del proyecto, los tiempos de ciclo se acortan, lo que conduce a plazos reales más cortos. En este gráfico hemos elegido enfatizar el plazo más realista indicando que “Objetivo N” es ahora “Objetivo N+a”. Los plazos pueden ser más cortos en el Nivel 2 que en el Nivel 1, pero la relación exacta dependerá de la predictabilidad y efectividad de línea base de los procesos de la organización cuando comenzó su programa de mejoras al proceso de software. Las mejoras en la predicción de los resultados de un proyecto representadas en la Figura 2.4 suponen que los resultados del proyecto de software se vuelven más predecibles a medida que se elimina el ruido, a menudo bajo la forma de trabajo hecho dos veces, del proceso de software. Sistemas sin precedentes complican el panorama, ya que nuevas tecnologías y aplicaciones disminuyen la capacidad del proceso aumentando su variabilidad. Incluso en el caso de sistemas sin precedentes, las prácticas de administración e ingeniería características de las organizaciones más maduras ayudan a identificar y tratar los problemas más temprano en el ciclo de desarrollo de lo que serían detectadas en organizaciones menos maduras. En algunos casos, un proceso maduro significa que se identifican proyectos “fallidos” más temprano en el ciclo de vida del software, y la inversión en una causa perdida es minimizada. 8

×