archivo

Archivo de la etiqueta: componentes

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

Tanto si tienes externalizadas las tareas de programación, como si no o tu empresa se dedica al desarrollo de software, resulta esencial la existencia de un libro blanco de desarrollo que marque una línea tecnológica y de arquitectura para los sistemas de información.

De esta forma el desarrollo de los proyectos es homogéneo y facilita las tareas de mantenimiento. Además, supone un ahorro de costes, ya que el desarrollo bajo un paraguas común facilita la existencia de un framework y de una colección de componentes estable.

El libro blanco de desarrollo supone también una métrica cualitativa de medida de la calidad de los desarrollos en cuento a lo que a tecnología y arquitectura se refiere, algo que resulta fundamental.

El libro blanco de desarrollo debe centrarse en la selección de buenas prácticas, tecnologías, patrones y arquitecturas para el desarrollo de software para cada uno de los paradigmas de sistemas de información en los que se desarrolle. El libro blanco debe marcar un camino y digo camino y no línea, ya que es recomendable ser flexible para determinadas soluciones, dando la posibilidad de utilizar distintas alternativas. Además debe huir de soluciones “propietarias” (en el sentido de que sean soluciones particulares de una empresa en cuestión) a nivel de framework y adoptar componentes que resuelvan problemáticas funcionales recurrentes sean o no “propietarios” en el sentido indicado anteriormente.

Evidentemente si trabajas en una empresa de desarrollo de software debes desarrollar según las directrices tecnológicas que te marque el cliente, pero en el caso de desarrollos internos, desarrollos I+D o desarrollos para clientes que no te marquen una directriz tecnológica sí que resulta muy interesante el uso de un libro blanco de desarrollo.

Otros aspectos importantes que debe cubrir un libro blanco debe ser la organización del software y el procedimiento de entregas, es decir, qué sistema de control de versiones utilizar, cómo utilizarlo, cuál debe ser la política de etiquetado, qué solución utilizar para automatizar la realización de pruebas unitarias, despliegues, cuál es la política a seguir para el paso a pruebas y/o producción del sistema, etc…

Como se puede apreciar, un libro blanco de desarrollo bien hecho, no está al alcance de cualquiera, de hecho se escapa, en mi caso, varios millones de leguas de mi capacidad técnica. La persona o personas que lo realicen deben tener un gran conocimiento de arquitecturas y tecnologías software, estar muy al día de todas ellas y tener una gran experiencia en el desarrollo y gestión de proyectos de desarrollo de software.

Desde hace unos pocos años está muy de moda el concepto de producción industrializada de software, queriendo dar una semejanza entre los procesos industriales de fabricación de coches, lavadoras, ordenadores, etc… y el proceso de desarrollo de software.

El concepto de producción industrializada aplicada al software es relativamente reciente, aunque se viene aplicando en las empresas de desarrollo de software desde prácticamente los inicios de la programación y se ha visto reforzado en los últimos años con la aparición de potentes frameworks de desarrollo, potenciados por las distintas empresas para reducir los costes de desarrollo y la programación aplicando patrones de diseño y la reutilización de componentes de análisis, software y documentales.

Es decir, las empresas desarrolladoras de software siempre van a intentar reducir los tiempos de desarrollo, aplicando algunos conceptos de lo que es la producción industrial. No obstante, en el software hay que tener en cuenta que en la mayoría de los casos se trata de un desarrollo a medida, lo que provoca que soluciones software parecidas tengan un enfoque distinto en función del cliente que la ha encargado. Esto rompe el concepto de producción industrial y nos dirige a un proceso más realista como es el del desarrollo moderno de software basado en arquitecturas que utilizan patrones de diseño, un framework de base y un catálogo de componentes.

Ya he hablado muchas veces de los frameworks de desarrollo, desde lo que son las piezas base del mismo, hasta llegar al nivel de componentes reutilizables (de alto y bajo nivel en función del proyecto), pasando por la selección de una arquitectura óptima para el proceso de desarrollo.

Todo lo anterior ahorra costes de desarrollo y si el framework es estable, pues también asegura un número de errores mínimo provocado por los mismos, por lo que también supone una buena base para la calidad de la entrega.

En este post, hablo de ir a más, de crear componentes software a nivel de aplicación, diseñado de tal forma que con una parametrización de la misma pueda ser implantada en diferentes organizaciones. Lo de la parametrización es lo óptimo, sé que no siempre se puede llegar a ese punto, pero por lo menos se debe lograr que esas piezas completas de software se puedan adaptar a una organización aplicando los menores cambios posibles sobre su código.

Diseñar software así no es sencillo, pero tener un catálogo de productos software disponibles para su instalación y parametrización supone unos beneficios en cada venta muy considerables, además de situarte frente a tus competidores en una situación privilegiada.