|
¿Puede programar un programa? |
|
|
|
29.06.2005 |
 Juanjo Navarro publica en un interesente post que las herramientas CASE no llegarán a reemplazar el trabajo de los programadores.
Desde luego la hipótesis de que las herramientas desarrolladas para facilitar nuestro trabajo, lleguen a acabar con nuestra profesión es un contrasentido, pero el que consigan eliminar la parte más mecánica y por tanto menos "humana" no se si será posible, pero es la razón de ser de estas herramientas, y hacia donde apunta su evolución.
Para responder a la pregunta de Juanjo deberíamos consensuar antes ¿Cuál es el trabajo de los programadores?.
Programador es un término ambiguo, y considerando una interpretación amplia; la que habitualmente se emplea en entornos de desarrollos de pequeño tamaño, programador es quien analiza el problema y concibe la solución, quien la diseña, la codifica, prueba, implementa, mantiene las versiones de requisitos, código, ejecutables, manuales, etc...
En este caso, como apunta Juanjo, deberíamos entrar en la ciencia-ficción para suponer que las herramientas serán capaces de realizar el trabajo de los programadores.
Si restringimos el significado del término programador, en contraste con otros como analista, ingeniero de software, consultor IT, etc. Y como también es frecuente en entornos de sistemas más complejos, llamamos "consultor" o "analista de requisitos" a quien estudia el problema y concibe la solución, y también analista a quien diseña el sistema de software, y programador a quien lo codifica; en este caso sí que se puede considerar que el trabajo de los programadores está en el punto de mira de un grupo de herramientas case: codificación, pruebas, gestión de la configuración, etc.
Posiblemente no lleguen a suprimir la intervención humana para llevarlas a cabo, pero su objetivo es reducirla en el mayor porcentaje posible.
Las cuestiones más difíciles a las que se enfrentan se polarizan en dos grupos:
1.- La realidad de los entornos de desarrollo de software.
La separación entre el trabajo de estudiar el problema y diseñar la solución por un lado; y su traslación a código e implementación en el sistema es más teórica que práctica, y muy pocos son los entornos en los que el diseño del software alcanza niveles de formalidad, rigor y detalle suficientes para no plantear ambigüedades y cuestiones de diseño pasadas por alto, que se deberán solucionar en la traslación a código.
2.- El principal problema con el que se van a encontrar las herramientas CASE: conseguir que el diseño llegue a quedar plasmado en el código sin perder el grado de idoneidad de solución, sin producir código rígido, frágil, inamovible, viscoso, complejo y opaco. (v. cuestiones sobre diseño).
Estas son en el fondo las habilidades que diferencian a los buenos de los malos programadores. Si no lo solucionan bien, tendremos herramientas que producirán resultados equiparables al de un equipo de malos programadores.
Ninguno de estos problemas es fácil; y sin demasiado riesgo se puede predecir que al menos durante algunas décadas estas herramientas no lograrán un nivel de éxito mayor que el que comparativamente tienen hoy los programas de traducción automática de textos: logran resultados en "indio", que se pueden entender, que sirven de ayuda a traductores profesionales para desbrozar inicialmente los textos, pero que ofrecen resultados no mucho mejores de lo que podría realizar un mal estudiante de idiomas.
 |
RSS de los comentarios
Las herramientas CASE en todo caso pueden intentar automatizar ciertas partes del desarrollo mecanicas, y precisamente pasar del diseo a la implementacin no creo que pueda encuadrarse dentro de las tareas mecanicas.
Se podr᳭a llegar a decir que esto es porque los diseos no especifican con suficiente rigor todos lo que estas herramientas necesitarian para producir el cdigo final, pero claro si en el diseᳱo quedarn especificados todos los detalles que se deben tener en cuenta en la implementacin con total rigor lo que en realidad estar᳭a ocurriendo es que habriamos cambiado de lenguaje de programacin, programariamos "pintando cajas" en lugar de "escribiendo cdigo".
Programar aunque parezca lo contrario no es "escribir c㳳digo", es partiendo de una especificacin de un problema en un nivel de abstraccin que no cubre todos los detalles llegar a una nueva especificaci㳳n que si cubra esos detalles que no se tienen en cuenta en la etapa anterior.
Si eliminamos estas fases intermedias y en el diseo especificamos todos los detalles "pintando cajas", en realidad lo que estamos haciendo es eliminar la fase conceptual de diseo y ponernos directamente a programar.