Proyectos con varias disciplinas
Desenvolupament No Comments »Atención: tocho de post que me sirve de terapia para canalizar las tensiones sufridas durante la última puesta en marcha.
Las clasificaciones dependen de lo que se quiera clasificar. Dicha esta perogrullada, una posible clasificación de los proyectos informáticos serían los que dependen únicamente de los informáticos y el cliente final, y por otro lado, los que dependen de los informáticos, profesionales de otras disciplinas y el cliente final.
En esta última clase, surgen problemas que hay que tener en cuenta, inexistentes si únicamente hay que tratar con el cliente final. Ejemplos del primer caso serían una web o un programa de gestión, en que como mucho, externamente se puede depender del ISP, pero que suelen ” hablar el mismo idioma”. Un ejemplo del segundo sería una automatización ( de un riego de cultivos, una planta, etc ). Aquí, a parte, pueden entrar en juego maquinistas, instaladores de componentes mecánicos, electricistas o electrónicos. El problema es que los informáticos piensan como informáticos, los electrónicos com tal, los electricistas, operarios, o montadores a su manera, etc. En términos informáticos, la API de intercamio de información entre estos gremios no está bien definida y puede llegar a requerir más atención nuestra de la estimada inicialmente. Y normalmente, la parte informática es la última en implementarse, con el consiguiente peligro de tener que absorber los posibles cambios o descoordinaciones en los pasos anteriores.
¿Cómo plantearse estos proyectos? Pues no tengo una lista de 10 reglas, ya que mi experiencia no es tan dilatada, pero según los casos que me he encontrado, dependerá básicamente de lo que se vaya a automatizar y de quién lleve el peso del proyecto. Por lo que he visto, contra más tierra haya, más problemas podemos tener. Es decir, si es por ejemplo una planta, seguramente el responsable de sistemas tenga claro lo que quiere y trabajará conjuntamente con los electrónicos para que controlen los procesos y con los informáticos para que recojan todos esos datos y los exploten (Scada). Pero si en el proyecto hay tierra, hay obras; y si hay obras, lógicamente el peso del proyecto lo lleven ingenieros de caminos, con jefes de obra, encargados y tal que, por lo que yo he visto, el tema de la automatización lo tienen más flojo, o al menos, están menos sensibilizados a la hora de por ejemplo, vigilar no cargarse un bus de comunicaciones con una máquina por hacer un agujero precipitadamente.
En estos proyectos, seguramente desde que se comienza la obra hasta que lleguemos nosotros a instalar el software pasen varios meses, con los consiguientes cambios que hayan podido haber durante el transcurso de ésta, algunos de los cuales podrían afectarnos directamente. Lo bueno sería identificar en nuestra aplicación cuáles son los elementos críticos que si sufriesen alguna modificación podrían tener un impacto grande sobre ella, y estar atentos durante el desarrollo de la obra por si se modificasen. Por ejemplo, en una automatización de riego de varios kilómetros, quizás hemos contado con montar 3 buses de comunicaciones y 3 puestos de control. Para ello nos han asegurado enganches eléctricos en ciertas zonas. Podría darse el caso de que uno de estos enganches se retrase mucho o que simplemente nos diga luego la compañía que ahí no puede ir: ¿nuestra aplicación es capaz de soportar un cambio de situación de los puestos de control? O hay que hacer un nuevo bus provisional porque antes de la puesta en marcha no se podrán unir dos tramos: ¿nuestra aplicación soporta el añadido de un nuevo bus? A ver, soportar lo debería soportar, pero ¿lo podemos reconfigurar fácilmente?Debemos actualizar un sistema viejo con comunicaciones por radio a uno con comunicaciones por cable. A última hora, por retrasos en las obras, vemos que no dará tiempo a actualizarlo todo antes de la puesta en marcha: ¿soporta nuestro sistema funcionar en modo mixto?
Otro punto es el intercamio de información entre la parte electrónica (autómatas, sensores, actuadores) y nosotros. Aunque informáticos y electrónicos son más afines, no hay que confiarse. Por ejemplo, en el control de algún proceso, si no lo hemos tenido que diseñar nosotros, únicamente nos deberán pasar las variables necesarias para actuar sobre él; fácil. El problema puede venir si nosotros tenemos que diseñar el algoritmo de control y no somos quienes programamos los autómatas. Se piensa un algoritmo y se le pasa a los programadores de autómatas. Pero éstos, al menos con los que yo he trabajado, suelen usar Grafcets para programarlos. De momento nunca hemos conseguido que el algoritmo haga lo que se pensó al 100%. ¿Qué suele suceder entonces? Que es la parte final, se va contrareloj, se testea y si el control funciona en líneas generales, ya está. Entonces, aún quedando pequeños detalles que en según qué circunstancias el control acaba haciendo “algo parecido” a lo pensado inicialmente, resulta difícil justificar un retraso en la entrega porque el algoritmo no actúe exactamente como se pensó, si está cumpliendo en un 95% su funcionalidad.
Como resumen, en proyectos de este tipo, mejor tener muy bien identificados los puntos críticos de nuestra aplicación y estar muy atentos a posibles cambios que les puedan afectar.
Recent Comments