Opinión sobre porqué el desarrollo de software no es como la ingeniería. El autor compara el software con la construcción de puentes, y también hace una interesante analogía sobre la evolución del juego del poker desde que se popularizó el juego online [en inglés].
#3:
#1 Cierto... desarrollar software a partir de unas especificaciones es extremadamente sencillo, al igual que caminar sobre el agua... tan solo se necesita que ambas cosas estén congeladas.
Yo comparto su opinión, pero por otro motivo: En cualquier ingeniería "tradicional" está muy clara la diferencia entre diseño e implementación, sin embargo, en proyectos software la cosa no está tan clara. Es más, todavía no saben cual es el coste porque tiene hay muchísima más sinergia entre proyectos software que puentes.
Nota: No creo que el hecho de no ser ingeniería haga a los desarrolladores software menos que a los ingenieros de puentes.
#2 preguntale a cualquier ingeniero de caminos, o industrial, y verás la imperiosa necesidad que tienen de decir que los 'informaticos no sois ingenieros de verdad'. Yo me he hartado de entrar en flame wars por esto mismo.
Al hacer software a medida se depende mucho de los requisitos del cliente por lo que nos encontramos con que si estos cambien el proyecto cambia....
Con la similitud del puente... ¿Qué pasaría si el puente es diseñado para trenes de tipo X y de repente aparece un nuevo tren mucho más molón que debe circular por esa vía pero que el puente no está adaptado para ello? ¿O qué pasaría si de repente aparece una nueva normativa que hace meter arcenes de 5 metros? Cambian los requisitos por lo que hay que cambiar el enfoque.... Pues eso es lo que nos pasa a nosotros... Si cogemos y cuando el cliente nos dice... "Oye y si....".. Nosotros le decimos... "Mire... la hoja de requisitos.... no contempla eso... Lo siento... " ya estaría... tendríamos que hacer el mantenimiento del puente como dice el señor este pero no un V2.0...
#8 Es una interrogativa indirecta de cajón, hombre. El porqué junto sólo se usa como sustantivo "no entiendo el porqué de todo esto". Mírate atentamente ese enlace que me pones y verás que el único porque que se puede usar en el título es por qué.
Lo he enviado porque me ha gustado mucho lo que cuenta sobre el poker, la verdad es que tiene mucha razón: en muy poco tiempo, el juego ha cambiado muchísimo.
Sobre el desarrollo de software, no menciona (o solo muy de pasada) el tema que para mi diferencia al software de la ingeniería tradicional: la falta de unos requerimientos sólidos y bien estudiados por parte del cliente.
Si los 'clientes' que necesitan un puente cambiasen de idea igual que los que quieren software, a ver que puentes saldrían!
#1 Cierto... desarrollar software a partir de unas especificaciones es extremadamente sencillo, al igual que caminar sobre el agua... tan solo se necesita que ambas cosas estén congeladas.
#1 hombre, si tú entiendes desarrollar software a hacer la web salchichera de tu primo el carnicero, que la haces en dos sentadas y la cambias al gusto... pues sí.
Ahora bien, si tienes que diseñar el programa que va a usarse en red de empresas, digamos todo el control de billetes de las agencias de viajes, centralizado, eso lleva un estudio previo, unas especificaciones, y un proyecto que te cagas.
Y eso de cambios de última hora nanain, si acaso en el maquillaje final.
Nada más que el diseño de la base de datos relacional es un despiporre de esutdio, no lo vas a cambiar al final, sería como intentar cambiar un puente... afecta a todo el diseño.
Pero claro, si solo has diseñado una base de datos relacional de dos tablas para poner el título y el autor de tus cds en access...
Por cierto, ¿tú qué has hecho en tu vida con los ordenadores? porque programar grandes cosas, no, por supuesto.
Si realmente el cliente supiera lo que quiere, los proyectos a medida serían menos dramáticos. Pero eso también es culpa de los comerciales y una serie de factores extras. Esta imagen es antigua, pero lo explica claramente:
Creo que os estais yendo por las ramas, par mi el motivo es que mientras las compañias informaticas continuen poniendo en las ELU que no se hace responsables de las consecuencias que acarree el fallo del software, los programadores, de ingenieros, nada de nada; dile a una aerolinea que no te haces responsable de las consecuencias y de los daños producidos por un accidente causado por un fallo de diseño del avion que le quieres vender y que en caso de que se demuestren fallos de diseño lo unico que haras será darle un avión nuevo, a ver cuantos te compran, o un arquitecto que ponga una "disclaimer clause" donde dice que no se hace responsable de los daños causados por un fallo estructural debido a un error de diseño, a ver como se rien de el.
La ingeniería es eso, garantizar lo diseñado, y si no asimir la responsabilidad; vamos, la "firmita", si no hay "firmita", no hay ingeniería de programación que valga.
Y sí, se eso de que la informatica no es una ciencia exacta, que un programa es muy complejo y no se pueden preveer todas las posibilidades que se daran durante su ejecución y todo eso; la medicina tampoco es una ciencia exacta y por eso no es una ingeneiría (aun así los medicos, al firmar los informes medicos o diagnosticos tienen que asumir muchas veces responsabilidades juridicas por sus errores debido a la "firmita").
Comentarios
Yo comparto su opinión, pero por otro motivo: En cualquier ingeniería "tradicional" está muy clara la diferencia entre diseño e implementación, sin embargo, en proyectos software la cosa no está tan clara. Es más, todavía no saben cual es el coste porque tiene hay muchísima más sinergia entre proyectos software que puentes.
Nota: No creo que el hecho de no ser ingeniería haga a los desarrolladores software menos que a los ingenieros de puentes.
#2 preguntale a cualquier ingeniero de caminos, o industrial, y verás la imperiosa necesidad que tienen de decir que los 'informaticos no sois ingenieros de verdad'. Yo me he hartado de entrar en flame wars por esto mismo.
Pues yo no comparto su opinión....
Al hacer software a medida se depende mucho de los requisitos del cliente por lo que nos encontramos con que si estos cambien el proyecto cambia....
Con la similitud del puente... ¿Qué pasaría si el puente es diseñado para trenes de tipo X y de repente aparece un nuevo tren mucho más molón que debe circular por esa vía pero que el puente no está adaptado para ello? ¿O qué pasaría si de repente aparece una nueva normativa que hace meter arcenes de 5 metros? Cambian los requisitos por lo que hay que cambiar el enfoque.... Pues eso es lo que nos pasa a nosotros... Si cogemos y cuando el cliente nos dice... "Oye y si....".. Nosotros le decimos... "Mire... la hoja de requisitos.... no contempla eso... Lo siento... " ya estaría... tendríamos que hacer el mantenimiento del puente como dice el señor este pero no un V2.0...
#6 Pasa habitualmente, así pueden justificar el sobre-coste de la obra y gastarse 10 millones de euros en un puente que habían adjudicado por 5. ^_^
Yo lo único que sé es que ese porqué debería ir separado: Por qué etc.
#7 "Por qué sólo se usa en oraciones interrogativas, directas e indirectas"
http://www.edu365.cat/eso/muds/castella/porque/eines.htm
La frase no es interrogativa, es una afirmación, y por lo tanto no debería ir separado.
#8 Es una interrogativa indirecta de cajón, hombre. El porqué junto sólo se usa como sustantivo "no entiendo el porqué de todo esto". Mírate atentamente ese enlace que me pones y verás que el único porque que se puede usar en el título es por qué.
Joder, parezco Mourinho con tanto por qué.
#10 Al final me has convencido, pero ahora ya no puedo editarlo
#10 Bueno, pues ya te lo cambio yo...
#16 Gracias hombre!
Lo he enviado porque me ha gustado mucho lo que cuenta sobre el poker, la verdad es que tiene mucha razón: en muy poco tiempo, el juego ha cambiado muchísimo.
Sobre el desarrollo de software, no menciona (o solo muy de pasada) el tema que para mi diferencia al software de la ingeniería tradicional: la falta de unos requerimientos sólidos y bien estudiados por parte del cliente.
Si los 'clientes' que necesitan un puente cambiasen de idea igual que los que quieren software, a ver que puentes saldrían!
#1 Cierto... desarrollar software a partir de unas especificaciones es extremadamente sencillo, al igual que caminar sobre el agua... tan solo se necesita que ambas cosas estén congeladas.
#3 muy buena esa!!!
#1 hombre, si tú entiendes desarrollar software a hacer la web salchichera de tu primo el carnicero, que la haces en dos sentadas y la cambias al gusto... pues sí.
Ahora bien, si tienes que diseñar el programa que va a usarse en red de empresas, digamos todo el control de billetes de las agencias de viajes, centralizado, eso lleva un estudio previo, unas especificaciones, y un proyecto que te cagas.
Y eso de cambios de última hora nanain, si acaso en el maquillaje final.
Nada más que el diseño de la base de datos relacional es un despiporre de esutdio, no lo vas a cambiar al final, sería como intentar cambiar un puente... afecta a todo el diseño.
Pero claro, si solo has diseñado una base de datos relacional de dos tablas para poner el título y el autor de tus cds en access...
Por cierto, ¿tú qué has hecho en tu vida con los ordenadores? porque programar grandes cosas, no, por supuesto.
#12 Resulta que he hecho proyectos para empresas bastante mas grandes que la web del primo salchichero, y creeme, la cutrez sigue igual.
Me he hartado de clientes grandes que se pasan el diseño por el forro, mas incluso que las cosas para clientes pequeños que hacía cuando empezaba.
No se en que mundo vives tu (en el de yupi, tal vez), pero los clientes cambian de especificaciones, y por eso los proyectos van como van.
#12 "Por cierto, ¿tú qué has hecho en tu vida con los ordenadores? porque programar grandes cosas, no, por supuesto."
Creo que aquí solo hay uno de los dos que es un mindundi que tiene que demostrar algo. Y no soy yo.
#0 "Por qué", no "Porqué".
Si realmente el cliente supiera lo que quiere, los proyectos a medida serían menos dramáticos. Pero eso también es culpa de los comerciales y una serie de factores extras. Esta imagen es antigua, pero lo explica claramente:
http://salimsribasuki.files.wordpress.com/2010/03/software-design-at-its-finest.jpg
Creo que os estais yendo por las ramas, par mi el motivo es que mientras las compañias informaticas continuen poniendo en las ELU que no se hace responsables de las consecuencias que acarree el fallo del software, los programadores, de ingenieros, nada de nada; dile a una aerolinea que no te haces responsable de las consecuencias y de los daños producidos por un accidente causado por un fallo de diseño del avion que le quieres vender y que en caso de que se demuestren fallos de diseño lo unico que haras será darle un avión nuevo, a ver cuantos te compran, o un arquitecto que ponga una "disclaimer clause" donde dice que no se hace responsable de los daños causados por un fallo estructural debido a un error de diseño, a ver como se rien de el.
La ingeniería es eso, garantizar lo diseñado, y si no asimir la responsabilidad; vamos, la "firmita", si no hay "firmita", no hay ingeniería de programación que valga.
Y sí, se eso de que la informatica no es una ciencia exacta, que un programa es muy complejo y no se pueden preveer todas las posibilidades que se daran durante su ejecución y todo eso; la medicina tampoco es una ciencia exacta y por eso no es una ingeneiría (aun así los medicos, al firmar los informes medicos o diagnosticos tienen que asumir muchas veces responsabilidades juridicas por sus errores debido a la "firmita").
http://www.dondado.es/2007/08/la-responsabilidad-en-los-programas-de-ordenador/
#19 Perdón EULA http://www.google.es/url?sa=t&source=web&cd=2&ved=0CCQQFjAB&url=http%3A%2F%2Fes.wikipedia.org%2Fwiki%2FLicencia_de_software&ei=iOwMTuOjHsTHsgad1LD1Dw&usg=AFQjCNH-kF2tq3RUb9w6Ai3mX45X7Wusfg&sig2=QuGgNU8HF_JCSen-GdSRzQ