Presentación
- ¿Qué sabe acerca de los desarrolladores de software a su cargo?
- ¿Sabe cuántos defectos se inyectan?
- ¿Sabe cuánto cuesta remover cada defecto?
- ¿Sabe en cuál fase se inyectan/remueven los defectos?
- ¿En su organización se dedica 30% ó 40% o más a testing? ¿Sabe que eso es altamente inefectivo e ineficiente?
- ¿Sabe cuál es la cantidad de líneas de código fuente que producen por hora?
- ¿Quiere mejorar el costo o el plazo de sus proyectos de software?
El software es un elemento cada vez más crítico en todas las facetas de la vida humana, además de ser uno de los móviles más importantes de la economía mundial, está presente en virtualmente todas las actividades del ser humano de nuestros días y esto está acelerando cada vez más.
Sin embargo nuestras prácticas para hacer software, no van a la par de los tiempos y aunque el software es cada vez más necesario, hoy nuestras prácticas continúan siendo pobres y la sociedad no tiene más que tolerarlas.
Es muy común ver que el *modelo* para desarrollar software está basado en tratar de programar lo más rápido posible y luego iniciar las extensas etapas de pruebas, donde tratamos de “descubrir” los defectos y corregirlos, mientras los cronogramas van venciendo, los presupuestos se van agotando, y la calidad es cada vez más una figura lejana que todos queremos pero que rara vez podemos alcanzar. En ciertos círculos este paradigma para hacer software se llama “Codifica&Corrige” (Code&Fix) o “Rápido&Sucio” (Quick&Dirty)
Watts Humphrey, uno de los visionarios originales del CMM (Hoy CMMI), nos explica:
“El CMMSM provee una excelente dirección para la gestión, pero su principal impacto está en los managers y su personal técnico. El CMMSM no afecta directamente el trabajo de los ingenieros (de software), ellos y sus equipos están todavía retados. No existe duda de que una mejor gestión ayuda, pero pronto me di cuenta de que hasta que no cambiemos las prácticas mismas de ingeniería de software, nunca podríamos lograr una verdadera capacidad de ingeniería de software, por ello el siguiente reto fue motivar a los grupos de ingeniería a hacer precisamente eso, quería que ellos conozcan los mejores métodos, pero también quería que ellos realmente los usen todos los días. Las técnicas que desarrollé para hacer esto se llaman Personal Software Process (PSPSM) y Team Software Process (TSPSM)…” [Humphrey 2002]
[Humphrey 2002] Humphrey, Watts S. – Winning with software An Executive Strategy. Addison-Wesley, 2002 – 7th printing 2008. Preface Pg. xiv |
Contáctenos: