archivo

Archivos diarios: octubre 20, 2010

No hace mucho tuve una charla con un amigo que es totalmente partidario de los procesos de industrialización del software y que entiende el proceso de desarrollo, una vez elaborado el análisis, como si fuera una cadena de montaje.

Me comentaba que conseguir eso implicaba trabajar, hablando en términos muy generales, de la siguiente manera:

– Los analistas discutirían el diseño del sistema con los arquitectos (en el caso de que hubiera alguna contingencia que hiciera necesario esto).

– Los analistas entregarían el diseño a uno de los responsables de recepción de trabajo de la factoría que se encargaría de distribuir el trabajo en el equipo.

– Dentro del equipo de la factoría habría un perfil asignado al proyecto que se encargaría de ensamblar los componentes y de verificar si el sistema cumple las especificaciones del diseño y del análisis.

– Una vez construido el proyecto (o en diversas iteraciones) el mismo pasaría a ser revisado por un departamento de calidad que haría las verificaciones finales del producto previas a la entrega.

La visión de mi amigo no es ni mucho menos mala, es simplemente otra opción en el proceso de desarrollo de software, es otra manera de hacer las cosas y que puede ser muy rentable si se dan las condiciones necesarias (o se reunen muchas de ellas para trabajar de esa manera).

Algunas de esas condiciones pueden ser las siguientes:

– El proceso de desarrollo de software desde su concepción hasta su entrega está regido por procesos, de manera que en cada fase cada cual conozca su rol y las tareas que debe realizar. Existirían personas encargadas de velar por el cumplimiento y mejora continua de los procesos.

– Los requisitos se encuentran cerrados en el momento en que se entrega el diseño a la factoría. Todos sabemos que eso es bastante complicado de conseguir ya que muchos usuarios terminan por afinar el concepto que tienen de aplicación conforme van viendo plasmada su construcción y a veces estos detalles son los que marcan las diferencias entre una buena terminación y otra no tan adecuada. Esto se complica sobre todo si el proyecto es de gran magnitud.

Pese a que es complicado y yo personalmente soy partidario de ser lo suficientemente flexible con el usuario y dar la posibilidad de introducir cambios menores en los requisitos más allá del análisis (con el coste y riesgos que ello conlleva), si el analista funcional hace un buen trabajo y/o se prevén fases de mantenimiento evolutivo posteriores y/o se opta por un desarrollo incremental del sistema sí que sería posible un escenario donde los requisitos estuvieran debidamente cerrados (no necesariamente al 100% pero sí muy aproximado a ese límite) en la fase de construcción.

Un inconveniente que se puede plantear con esta dinámica de trabajo es la separación entre el equipo funcional y el equipo que realiza la construcción del sistema de información. Esa frontera puede ser causa de problemas salvo que se establezcan mecanismos adecuados de interlocución entre el equipo de personas que construyen y los analistas funcionales, supuestamente si todo estuviera bien especificado en el diseño y en el análisis la comunicación no debería ser necesaria, pero eso es un modelo teórico a mi juicio ya que requeriría que no quedasen resquicios en el diseño y en el análisis, algo que resulta muy complicado y que se complica todavía más conforme se incrementa la complejidad y tamaño del sistema.

Si los mecanismos de interlocución funcionan y todos reman en la misma dirección, estos problemas pueden minimizarse, pero si no es así el equipo de construcción tenderá a rellenar los huecos del análisis y el diseño, algo que es muy arriesgado ya que ellos no han participado en la etapa de definición funcional de la aplicación y no han trabajado con quienes van a utilizar finalmente la aplicación.

Podría pensarse que la colaboración entre los equipos de trabajo debería ser algo fluido, pero no necesariamente va a ser así, sobre todo si los responsables funcionales y los del proceso de construcción son distintos y pertenecen a departamentos diferentes, lo que implicaría que el jefe común entre ambos equipos estaría situado bastante por encima en la jerarquía de la organización, lo que dificultaría las tareas de coordinación en caso de conflicto (cuanto más arriba esté quien realiza estas tareas, pierde la visión del día a día, este tipo de problemáticas no les resulta de interés, en función de otras que suelen tener (principalmente de carácter económico de los proyectos o departamentos a su carga) y además asusta más requerir su participación porque se piensa que su intervención puede ser semajante a la de un elefante cuando entra en una cacharrería).

– La construcción tiene que ser lo más homogénea posible. Es decir, en la medida de lo posible los desarrollos deben estar construidos siguiendo el mismo framework y automatizándose en lo posible el proceso de construcción mediante la utilización de generadores de código e incluso con la posibilidad de utilizar frameworks gráficos. Esto será posible cuando los clientes planteen libertad en cuanto a framework o arquitectura o exista un alto grado de compatibilidad entre la solución que requiere el cliente y aquella con la que se trabaja, en otros casos tales como aplicaciones desarrolladas siguiendo otra estrategia (y en las que se va a realizar mantenimiento evolutivo) o nuevos desarrollos que sigan otro framework habrá que aplicar otro tipo de estrategias para hacerse cargo de ellos.

Cuando el desarrollo sigue una línea diferente a la utilizada en la factoría lo ideal sería especializar un grupo de trabajo en el desarrollo con esa arquitectura, framework o tecnología, pero eso requeriría una vinculación a medio o largo plazo con el cliente y/o tener expectativas más o menos ciertas de negocio. ¿Por qué especializar? Pues porque la productividad va a ser mayor, no ya solo por el dominio que este equipo puede tener de la tecnología, sino porque se pueden adoptar soluciones (aunque sea paulatinamente) para mejorar el rendimiento en el desarrollo. Si el proyecto no es lo suficientemente grande, duradero o las expectativas de trabajar en otros proyectos similares no están claras, lo mismo hay que plantearse que la solución más adecuada no pasa porque el contrato (en el que caso de que se quiera o pueda asumir) lo realice la factoría, lo mismo resulta mucho más adecuado formar un equipo de proyecto tradicional para llevarlo a cabo.

En la charla, mi amigo tenía muy claro que había que invertir en el framework, en la generación de código y en la reutilización de módulos y componentes y que es absolutamente necesario tener a personas dedicadas exclusivamente a mejorarlo, a corregir incidencias y a asesorar y que había que perder el miedo a tener estas personas haciendo estas funciones, ya que aunque sean perfiles altos (deben serlo para que el resultado de sus trabajos sea el más óptimo posible debido al impacto que tendrá en el conjunto de proyectos) el retorno de la inversión está asegurado.

Hace bastante tiempo escribí un conjunto de articulos dedicados a la producción industrializada de software, si queréis echarle un vistazo os dejo a continuación sus enlaces:

Producción industrializada de software I
Producción industrializada de software II
Producción industrializada de software III
Producción industrializada de software IV
Producción industrializada de software V
Producción industrializada de software VI