Archivo

Archivos diarios: octubre 6, 2011

En algún artículo he tratado este asunto, son muchas las cualidades las que debe tener un buen desarrollador de software. Probablemente muy pocas personas o ninguna saque matrícula de honor en todas las variables y también pasa que existen determinados tipos de proyectos donde alguien puede obtener extraordinarios resultados, pero que en el momento en que cambia la tipología del mismo, el tipo de cliente, etc… los resultados se vuelven más normales o incluso negativos.

Conozco a muchos profesionales de la informática que valoran la capacidad intelectual de sus técnicos por encima de otras cualidades. Es importante, pero para mi es una cualidad más, que no vale más que otras muchas.

Sobre esto, hay una interesante reflexión de Gerald Marvin Weinberg: “Tener un alto cociente intelectual es como tener una CPU con una terrible velocidad de computación. Es un gran activo para la resolución de problemas, siempre y cuando los mismos no tengan una gran cantidad de entradas y salidas”.

El funcionamiento de un producto software se define mediante la integración de sus componentes internos y la integración con componentes externos.

En un ambiente de arquitectura del software donde la modularidad y la delegación de funcionalidades predomina sobre otros paradigmas y en donde los equipos de trabajo pueden estar en diferentes localizaciones geográficas, un gobierno adecuado de integración de componentes resulta fundamental para detectar cualquier anomalía lo antes posible.

CMMI no es ajeno a esta circunstancia y determina en su nivel 3 la necesidad de establecer una estrategia global. Perfectamente podría haber incluido a nivel de proyecto este proceso en el nivel 2, sin embargo la orientación del mismo a la administración o gestión de cómo se realiza al desarrollo y no a la definición de métodos de trabajo, es lo que ha hecho que este proceso al igual que otros pase a engrosar este nivel.

Por tanto, en este proceso se establece una metodología a nivel de organización en cuanto a la integración de componentes. Como en el resto de procesos, la definición de una estrategia global no consiste en la definición de un modelo único sino que permite escenarios en función de la tipología y características del proyecto.

En la descripción de este proceso se encuentra por un lado los pasos a seguir para preparar la integración (determinar la secuencia de integración, adecuar un entorno de integración y decidir cómo y a través de qué se realiza el proceso de integración), para garantizar la compatibilidad de las interfaces (mejor si se detectan problemas de este tipo antes de realizar la integración) y para realizar el propio proceso de integración (condiciones que tienen que cumplir los componentes con carácter previo a la integración, cómo realizar la misma y cómo evaluar el resultado final).

La implantación de este área de proceso no debe resultar complicada para la mayoría de las empresas de desarrollo de software ya que con carácter previo han tenido que gestionar de manera adecuada la gestión de la configuración (esencial para restar complejidad a este proceso) y porque generalmente cuentan con soluciones de integración de componentes y en muchos casos se aplican técnicas de integración continua y en menos, pero afortunadamente cada vez más, pruebas unitarias y técnicas rápidas de verificación estructural y funcional como smoke testing.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.199 seguidores