10 prácticas poco efectivas y la solución en CMMI

Foto: Erik Moeller
¿Cómo un proyecto llega a tener un año de retraso? Un día a la vez. (Frederick Brooks, Jr.) 
CMMI es un modelo de prácticas que ayudan al desarrollo de un producto de mejor calidad y al crecimiento del negocio. Considerar su aplicación en la organización implica cambios de hábitos y costumbres que resultan en grandes beneficios, pero que muchas veces deben romper paradigmas muy arraigados dentro del personal.

Andrew Oliver en un artículo publicado por InfoWorld "10 practices of highly ineffective software developers" relaciona las diez prácticas que utilizan los programadores por malos hábitos o presiones del gerente de proyecto y que provocan malos resultados. Esas malas prácticas pueden ser corregidas con las lecciones aprendidas y mejores prácticas establecidas en CMMI y obtener resultados efectivos.

Diez prácticas de los desarrolladores ineficientes
  1. Terminar el día sin escribir una prueba unitaria. Es una práctica habitual dejar que los errores se presenten y no hacer nada para evitarlos. En el modelo CMMI desde la definición de requisitos (RD) se establece la forma en que serán verificados como un mecanismo para demostrar que los requisitos son correctos, durante la codificación se establece la ejecución de pruebas unitarias (TS) y las actividades de verificación (VER) se establecen durante todo el ciclo de desarrollo para garantizar cubrir las expectativas del cliente.
  2. No hacer integraciones. Una forma de evolucionar progresivamente el producto es hacer integraciones parciales e ir comprobando como va funcionando. Las actividades de integración (PI) son continuas desde la fase inicial en que se identifican los requisitos, durante todo el proceso de desarrollo y hasta la integración final del producto.
  3. No utilizar herramientas de control de versiones. Las herramientas de control de versiones facilitan el proceso de construcción, pensar que obstaculizan la creación es perder de vista el problema que se provoca cuando no se tiene. Las prácticas de gestión de la configuración (CM) como área de proceso y consideradas en cada una de las áreas de proceso, en forma de práctica genérica, garantizan el control de los productos que se desarrollan.
  4. Liberar a producción sin considerar las ramificaciones. Está relacionado con el control de versiones, crear ramas del producto facilita trabajar con versiones intermedias, corregir fallas pero olvidarse de considerar las ramificaciones puede generar problemas mucho más complejos. Una adecuada gestión de la configuración (CM) debe ayudar a considerar esa situación.
  5. Esperar al final para pruebas de carga. Muchas veces no se considera la solución óptima hasta que se tiene una solución operativa que no es eficiente. La identificación de los atributos de calidad (RD), la definición de la arquitectura de solución (TS) y la verificación continua permiten optimizar el producto durante el ciclo de desarrollo sin esperar a que esté concluido.
  6. Desarrollar sin tener requisitos de capacidad o rendimiento. El software no funciona sólo por hacer lo que funcionalmente se espera sino dentro de las expectativas de uso y rendimiento que se tiene, su desconocimiento afecta la confiabilidad del producto. En la identificación de los requisitos (RD) es fundamental trabajar los atributos de calidad y expectativas de uso sobre el producto, que deben ser comprobados incrementalmente a través de las verificaciones (VER) y validaciones (VAL). 
  7. Esperar al final para involucrar a los usuarios. Es una necesidad de todo producto conocer la reacción de los usuarios que lo van a utilizar desde las etapas iniciales, no hacerlo es negar la importancia del uso que va a tener y trabajar para nadie. Las prácticas de verificación (VER) y validación (VAL) durante todo el ciclo de desarrollo buscan la confirmación no sólo del entendimiento de los requisitos sino también de que el producto final podrá ser utilizado.
  8. Comprar el desarrollo. Una de las cuestiones fundamentales en el desarrollo es qué tanto se puede comprar de una solución ya hecha. Las prácticas de solución técnica (TS) consideran la evaluación de las alternativas de solución y considerar la decisión de comprar, reutilizar o desarrollar los propios componentes de la solución para obtener un producto óptimo.
  9. Escribir sus propias utilerias. Evitar utilizar componentes "ya hechos" es una práctica poco efectiva que no aprovecha funcionalidades ya probadas. La evaluación de componentes reutilizables como parte de la solución técnica (TS) y la integración efectiva de éstos (PI), en la solución final, es parte del proceso de construcción del producto.
  10. Codificar directamente en el manejador de datos. El establecimiento de una arquitectura óptima del producto (TS) que permita cubrir los atributos de calidad y garantizar el mantenimiento, operación y evolución del producto en cada unos de sus componentes permite que el producto tenga un largo ciclo de vida.
El uso de las prácticas de CMMI, con el conocimiento y experiencia de la industria, facilita el desarrollo de productos de calidad. Su uso requiere entender la cultura de la organización y eliminar los vicios que perjudican los resultados que se esperan para el negocio. Entender adecuadamente estos beneficios y aplicarlos concientemente puede ser la gran diferencia entre el éxito y el fracaso de un proyecto.

2 comentarios:

  1. voy a poner en práctica el proyecto que tengo en mente pero primero tengo que armar las planillas en la computadora y tener todo preparado para comenzar estos pasos a seguir. voy a bajarme un antivirus ya que estoy teniendo problemas y tengo miedo de perder archivos mientras ya lo empiece a hacer. esta entrada servirá mucho para guiarme

    ResponderEliminar

CMMI v2, cinco puntos para entender la nueva versión del modelo

El mes de marzo del 2018 fue el lanzamiento de la versión 2.0 del modelo CMMI (Capability Maturity Model for Integration) por el CMMI Ins...