Contenidos
Introducción
Es básico hacer un análisis de deslocalización de la producción de un producto software antes de llevar a cabo esta deslocalización. Al menos se deberán analizar los siguientes aspectos:
- Qué tipo de producto software se tiene.
- Cuál es la estructura del equipo que lo está desarrollando.
- Qué proceso de producción de software está llevando a cabo y cuáles son los activos producidos.
A partir de este análisis, se podrán conocer y evaluar las alternativas de deslocalización de producción de software que pueden darse para garantizar el éxito así como los pasos previos a dar antes de aplicar estas alternativas.
Tipo de producto software
Dentro de esta fase de análisis de deslocalización de un producto software es necesario saber cómo está construido este producto, obteniendo una arquitectura del sistema. Al menos, obtener una arquitectura a alto nivel entre los subsistemas y módulos de cada subsistema del producto.
No tiene la misma complejidad en la deslocalización software si se parte de un sistema monolítico que si se parte de un sistema cuya arquitectura esté basada en microservicios. En el caso de un sistema monolítico no tiene la misma complejidad si se tiene un único monolito que varios monolitos con funcionalidades independientes.
Al final el objetivo será desgajar este monolito para minimizar la complejidad en la fase de deslocalización. Por lo que cuanto mayor sea el monolito y menos piezas tenga, mayor será la labor de refactorización y rediseño necesaria.
Habrá que hacer un inventario de las diferentes versiones de cada componente del producto, así como las dependencias entre las versiones de estos componentes (líneas base). Se deberá conocer qué repositorios de código hay para los componentes del producto, así como la tecnología de cada repositorio de código.
Aparte de la arquitectura del producto será necesario conocer también qué documentación técnica hay sobre el producto. Si existe documentación funcional de cada feature del producto, diseños detallados de su arquitectura y planes de pruebas de aceptación.
En cuanto a la parte de Operaciones, habrá que ver si existen manuales de instalación y despliegue, manuales de usuario y manuales de mantenimiento. De vital importancia es saber no solamente que exista esta documentación sino saber si está actualizada con respecto a lo que está implementado en el producto.
Estructura del equipo
La estructura del equipo influencia en la deslocalización del producto software. Será necesario estudiar los siguientes aspectos:
- Cuál es el rol y responsabilidades de cada miembro del equipo.
- Que comunicaciones se dan entre los miembros.
- Expertise técnico de cada miembro.
Roles y responsabilidades
Será necesario saber qué roles y responsabilidades hay en el equipo, ya sea porque se hayan identificado y asignado explícitamente a los miembros del equipo o porque implícitamente cada miembro lo haya adquirido con el paso del tiempo. Es importante saber si hay roles diferenciados o no. Un ejemplo de clasificación de roles es la siguiente:
- Jefe de proyecto.
- Responsable técnico de producto.
- Analista funcional.
- Analista/diseñador técnico.
- Desarrollador
- Tester
Se necesitará analizar qué rol o roles desempeña cada miembro. Aparte, habrá que conocer las responsabilidades asignadas a cada rol.
Comunicaciones
Según la siguiente cita de Conway se puede ver la relación directa que existe entre el diseño del producto y las comunicaciones que tienen lugar entre los miembros del equipo:
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure" .
(Melvy Conway, 1967)
Añadiría otra relación previa a la anterior y es la relación que existe entre los roles y las responsabilidades y las comunicaciones:
"Si tienes roles diferenciados, entonces tendrás comunicaciones diferenciadas".
Por poner un ejemplo, si tienes analistas, diseñadores y desarrolladores, lo más normal es que ocurran las siguientes comunicaciones:
- Entre el analista y el diseñador, para construir el diseño detallado a partir del análisis funcional. El diseñador hará preguntas al analista sobre el funcionamiento del sistema.
- Entre el diseñador y el desarrollador, para realizar la implementación a partir del diseño detallado. El desarrollador hará preguntas al diseñador sobre el diseño.
Por el contrario, si no hay roles diferenciados, entonces habrá comunicaciones sin diferenciar en cuanto a los aspectos que trata dicha comunicación.
Proceso de producción y activos
Como parte del análisis de deslocalización de un producto software, hay que estudiar el proceso de producción y los activos que se producen para ver como afectan a la deslocalización del producto software.
Tanto el proceso como los activos vienen derivados de los roles y de las responsabilidades que existan en el equipo. Por ejemplo, si no hay analistas en el equipo seguramente no haya una fase de análisis en el proceso de producción. O si la hay seguramente no se produzca el activo pertinente.
La siguiente tabla muestra la dependencia entre el rol y la fase de producción, así como el activo que se produce en cada fase.
| Rol | Fase | Activo |
| Analista | Análisis funcional | Descripción funcional del producto |
| Diseño | Diseño detallado | Diseño detallado del producto |
| Desarrollador | Implementación | Código del producto |
| Tester | Testing | Planes de pruebas de aceptación del producto |
| Adaptador de datos | Preparación de datos | Datos de configuración del producto |
Cabe mencionar que hay dependencias también entre los activos. Por ejemplo, si no hay una descripción funcional del sistema, difícilmente habrá planes de pruebas de aceptación del producto, ya que los testers no podrán definir estos planes sin tener una descripción funcional de referencia.
Es importante remarcar que son varios activos los que son fabricados durante el proceso de producción del software. Habitualmente se suele dar mucho peso al código del producto como activo. Pero, ¿que valor tiene un código sin contar con un diseño detallado o una descripción funcional del producto? En esta situación, mantener este código y hacerlo evolucionar será muy costoso o imposible.
Por otro lado, al tener al menos los activos identificados anteriormente, se abre la posibilidad a que diferentes roles puedan trabajar en el equipo. Si solamente tenemos al código como activo, en nuestro equipo solo podrá haber desarrolladores. Si admitimos la descripción funcional como activo de nuestra producción, entonces podrán trabajar en el equipo analistas funcionales que sepan del mercado. Y además, a partir de este activo se podrá construir otro activo más: los planes de pruebas del producto. Este activo dará la posibilidad a que en el equipo puedan trabajar testers.
Por último, según la naturaleza del producto, se puede producir otro activo más y que se corresponde con los datos de configuración del producto, fabricado por las personas de adaptación de datos.
El proceso de producción determina la forma en la que está construido el producto.
Si no se ha hecho un diseño detallado antes de comenzar a implementar, la arquitectura del producto no será de buena calidad y tampoco será homogénea aplicando los mismos patrones de diseño en los diferentes componentes del producto. Esto dificultará la implementación del producto y afectará a su calidad.
Si tampoco hay una descripción funcional del producto, el cliente no podrá ver el valor que aporta el producto a su negocio y será costosa su evolución futura incluyendo más features.
Si no se diseño un plan de pruebas de aceptación, no se tendrá una medida de la calidad del producto. Medida que será indispensable tener tanto para la organización que fabrica el producto como para el cliente que lo vaya a adquirir.
Conclusiones
Hemos visto que para hacer el análisis de partida antes de abordar una deslocalización de la producción de un producto software hay que ver como está construido el producto, qué roles, responsabilidades y comunicaciones se dan en el equipo así como las fases de producción y activos del producto.
Toda esta información hay que recopilarla y documentarla para que nos sirva de partida para la siguiente fase en la deslocalización y que trata sobre los pasos a dar antes de llevar a cabo esta deslocalización.