Testing y balas de plata
Esto es una aclaración breve a algo que dije en el Barcamp de Testing.
En 1986 Brooks decía "There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity." ("No hay un desarrollo invidual, ni en tecnología ni en técnicas de gerenciamiento que por sí mismo prometa incluso una mejora de un orden de magnitud en una década en productividad, en confiabilidad, en simplicidad")
Y estoy totalmente de acuerdo, a casi 30 años de la declaración de Brooks, seguimos sufriendo de muchos de los mismos problemas que en 1986. Agreguen a lo anterior los procesos de testing.
Mencioné en la plática que CMMI nivel mayor a 3 NO es más garantía de éxito en los proyectos de software que un 50%, y hay que aclarar:
- Sin CMMI > 3 las probabilidades de éxito caen al 25%
- Con CMMI > 3 Y otras técnicas, tus probabilidades suben a 75% o más
Las técnicas que combinadas producen proyectos exitosos son:
- Inspección formal de requerimientos, diseño y código
- Análisis estático de texto.
- Análisis estático de código
- Junta de Diseño de Aplicación
- Modelado de requerimientos
- Uso de puntos funcionales
- Métricas de calidad: Complejidad, detección de defectos, remoción de defectos.
- Herramientas automatizadas de seguimiento de defectos.
- Pruebas activas de calidad (>3% del staff total de la empresa)
- Especialistas en pruebas.
- Análisis de causa raíz
Ahora bien: CMMI es un conjunto de procesos (un metaproceso en sí mismo), con métricas, historial, repetibilidad, responsabilidades, etcétera, que puede incluir todos los factores de éxito de proyectos. De hecho, parte de la definición de los niveles más altos de CMMI es el proceso de mejora continua que nos permiten adoptar procesos que resulten en proyectos exitosos.
Entonces sí, aclarando de nuevo: CMMI 3 o mayor, solito, por sí mismo, sin otras técnicas de desarrollo y pruebas asociadas, apenas me garantiza por sí mismo un 50% de éxito en mis proyectos y sin embargo, no tener un proceso CMMI (o probablemente ITIL o algo similar) hace que las probabilidades de éxito de proyecto se reduzcan a sólo el 25%.
Lamento no haber sido lo suficientemente claro en la presentación.
(Y les recuerdo amiguitos: mis opiniones son mis opiniones y no representan a mis clientes, patrones, mentores, ex-patrones o cualquier otro que no sea yo mismo...)
2 comentarios:
De hecho, ni CMM ni su sucesor CMMI son un proceso o una definición de procesos ni nada que se le parezca. Son únicamente un modelo que nos orienta sobre las áreas en que deberíamos estar poniendo atención en nuestros procesos internos de desarrollo (sea cual sea el "brand" de este) y de acuerdo a nuestra situación actual.
Frecuentemente se asocia a CMM o CMMI con RUP, TSP/PSP u otras metodologías, o procesos (o meta-procesos o...) específicas, pero hay que tener en cuenta que p.e., RUP por sí mismo es solo un proceso CMM nivel 2. CMM/CMMI no nos va a decir "cómo" desarrollar software, pero si qué tipo de consideraciones deberíamos tomar en cuenta al hacerlo, y con qué énfasis.
De hecho, ni CMM ni su sucesor CMMI son un proceso o una definición de procesos ni nada que se le parezca. Son únicamente un modelo que nos orienta sobre las áreas en que deberíamos estar poniendo atención en nuestros procesos internos de desarrollo (sea cual sea el "brand" de este) y de acuerdo a nuestra situación actual.
Frecuentemente se asocia a CMM o CMMI con RUP, TSP/PSP u otras metodologías, o procesos (o meta-procesos o...) específicas, pero hay que tener en cuenta que p.e., RUP por sí mismo es solo un proceso CMM nivel 2. CMM/CMMI no nos va a decir "cómo" desarrollar software, pero si qué tipo de consideraciones deberíamos tomar en cuenta al hacerlo, y con qué énfasis.
Publicar un comentario