|
|
|
Secciones
Obrar mucho, y hablar poco; que lo demás es de loco.
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
(+1) Muy bueno el símil :-) (s/t)
(Puntos:1)( http://knocte.blogspot.com/ )
Re:Analista vs Programador
(Puntos:1)( http://www.tryo.scd.cl/ | Última bitácora: Miércoles, 21 Enero de 2004, 03:12h )
No puedo aguantarme, pero hay que decirlo, está muy buena la comparación, y deja más que claro las tareas del analista, que a veces se olvida de su tarea y se pone a codificar como condenado sin documentar nada, para tener de resultado una pesadilla, que ni el mismo puede mantener posteriormente.
Es importante saber como se ponen los ladrillos y las mezclas de cemento, pero no por eso uno se embarra las manos cuando hay otros que son expertos en eso.
Muy buena aclaración +1 Profundo
Re:Analista vs programador
(Puntos:2)( https://twitter.com/yapw | Última bitácora: Viernes, 13 Mayo de 2011, 21:21h )
Pero... ¿es comparable la construcción y el desarrollo de software? ¿el cliente cambia de opinión en mitad del desarrollo? ¿el edificio se cae el primer día y hay que volverlo a construir?
Queda bonito dejar clara la jerarquía del desarrollo, pero ¿es realmente útil? ¿no es cambiante?
Lo sé, demasiadas preguntas y ninguna respuesta, lo malo es que solo tengo preguntas [agile-spain.com]....
Aquí había una firma
Re:Analista vs programador
(Puntos:3, Interesante)( http://barrapunto.com/ )
Por eso escogí los sobrenombres de místico y matón. El místico es alguien que vive en un mundo de conceptos e ideas, y toda su producción es, normalmente, "abstracta". Y luego estaba el matón, que es el que se ensucia las manos con los cacharros picando código.
El problema es que mientras escribía el comentario me iban viniendo a la cabeza algunos recuerdos e ideas que al final acabaron en esa postdata (si la eliminas, verás como cambia todo de significado).
¿Cuál es mi problema entonces? Bueno... resulta que creo que no es buena idea intentar normalizar algo tan creativo como el desarrollo de software.
El problema del UML (en general, de todas las metodologías que yo conozco de desarrollo de software) consiste en que en el papel todo es muy bonito, pero cuando te pones a implementar te encuentras con que las cosas no son como inicialmente se había previsto. ¿Un mal diseño? No, simplemente que se está trabajando con unas condiciones que no son exactamente las mismas que se habían previsto, y se están teniendo unos problemas que al analista (o analistas) no se le(s) había(n) ocurrido ni en su(s) más salvajes sueños.
Sin embargo, a los que les ha tocado picar código se encuentran con que tienen que hacer unas chapuzas impresionantes llenas de apaños de todo tipo para poder ajustarse al diseño realizado. Esto es lo que está sucediendo en el proyecto en el que estoy trabajando actualmente.
¿Quiero decir que el UML es una mariconada? No, realmente no. Lo veo bien como una herramienta de apoyo, algo que te puede facilitar enormemente la vida al diseñar software. Pero no puedes basarte en ella como he visto a veces en la universidad (me han llegado a decir que tal o cual cosa no se puede hacer porque "no lo contempla el modelo". Genial, pero... ¿y si el modelo no puede reflejar lo que yo quiero decir, o lo hace de una manera muy farragosa?).
Respecto a lo de la construcción, hay una diferencia fundamental con respecto al desarrollo del software. Muy pocos arquitectos (¿ninguno?) trabaja de albañil, mientras que gente con conocimientos suficientes para ser analistas trabajan de programadores. Y aparte, un arquitecto no tendría por qué saber cómo se pone un ladrillo, mientras que un analista que no sepa hacer un "hola mundo" en algún lenguaje diseñará unas especificaciones muy muy muy pero que muy difíciles de implementar.
F. de la O.