Barrapunto

Bueno, es sencillo. Para convertirla en una ingeniería de verdad, basta con que pongan una asignatura de manejo del teodolito en el primer curso.

-------
Cinco minutos de incitación al consumismo, y volvemos enseguida

¿Y aparte de que si eres ingeniero eres supremo y si eres licenciado eres un pardillo que diferencia real hay entre una cosa y la otra?

María Ribera Sancho. ¿Tendrá la misma fiabilidad el resto de la noticia?

Yo creo que precisamente la clave está en el profesorado. Si los profesores se pusiesen de huelga y dijesen que se niegan a dar clases mientras se sigan manteniendo las actuales intenciones, no cabría más que aceptar unas peticiones que, por otro lado, son del todo razonables.

¿Tendrán entonces los informáticos responsabilidad civil y penal sobre sus diseños? ¿Estará prohibido el software libre, si no hay nadie con un título homologable que se responsabilice de el?

Aunque podría entender ausencia de artículo determinado en título de entrada por límite de caracteres de _slashcode_, no puedo pasar por alto eso de "Ingeniería informática" sin artículo. Queda horrible hablar sin artículos, por ejemplo: "Rey de España ha tenido accidente mientras esquiaba por autopista, sin llevar reglamentario chaleco reflectante. A barricadas, por triunfo de Confedereación."

Ha quedado como culo, no te parece.

jau
rostro pálido no saber fumar petardo

1) He tenido que dar cientos de explicaciones a gente incompetente que te toma por un friki

2) Sentí verguenza en unas jornadas tecnológicas cuando una ponente sueca pidio que alzaran el brazo aquellos que practicaban determinada práctica de ingeniería del software y una sóla persona de unas 100 levantó la manita (la ponente podía haber abierto los ojos un poco más, pero seguramente se hubiera hecho daño)

3) En un mes en Francia he tenido el respeto como profesional que no he tenido en 4 años en España.

Hay que reconocerlo, en general y al menos en desarrollo de software, damos pena. Puede ser un paso adelante para dejar de serlo.

Para aquellos que digan que la informática no es una ingeniería... habláis sin tener ni puta idea, probad a decir eso en una entrevista de trabajo para alguna empresa multinacional de software...

La unica verdad que hay es que si a un ingeniero de caminos se le cae un puente o edificio, se le desborda un canal, su carretera esta mal peraltada, etc. ira a la carcel y/o pagará una multa y/o perderá el titulo. Esto es así porque hay vidas en juego y estoy totalmente de acuerdo con ello.

En cambio me parece fatal,injusto con el resto de las ingenierias e injusto con todas las personas que dependen de programas informaticos para sobrevivir, que si el programa informatico de un avion falla y mueren 300 personas un ingeniero informatico no se responsabilice de nada.

Si la Ingenieria Informatica pasa a considerarse en todos los aspectos una ingenieria, se exigiran responsabilidades por los fallos de software, gente ira a la carcel, empresas pagaran multas millonarias por agujeros de seguridad, y todos disfrutaremos de un software de mejor calidad y tendremos una mejor calidad de vida.

Lo que no entiendo es como ha tardado tanto en pasar...

Me parece completamente absurda la discusión, porque no hay discusión posible.

1: La informática es una ingeniería y (barra) punto. Es un hecho.
Según la Real Academia Española:

ingeniería.

1. f. Estudio y aplicación, por especialistas, de las diversas ramas de la tecnología.
2. f. Actividad profesional del ingeniero.

¿Quién se atreve a refutar que la informática no es una tecnología cuya aplicación surge de un estudio previo por parte de especialistas? ¿Es que piensan que no es una actividad profesional?

2. Es una injusticia que a los ingenieros de una ingeniería no se les da el título de ingenieros. Otro hecho.

Conclusión: Los de MEC tendrán que darse cuenta de estos hechos. En otro caso, todos los perjudicados estamos obligados moralmente a reparar esta injusticia. ¿Qué les parecería si de verdad no nos comportásemos como ingenieros, como profesionales? ¿Se atreverían a tomar un avión, un tren, se someterían a novedosos tratamientos médicos? ¿Es que acaso piensan que sólo nos dedicamos a hacer páginas web? Por favor...

Bueno, ¿y si me dedico a la rama hardware? En muchas ingenierías también ocurre que hay muchas soluciones y cada una con ciertos puntos a favor y en contra.

Además como ya te he dicho, la ingeniería del software es sólo un parte de la informática.

"Una ingeniería tiene una base fuerte de matemáticas y física, y reconozcamoslo... no es el caso de la carrera de informática"

Será en la tuya...
Aquí van algunas: Álgebra, Cálculo Diferencial, Álgebra Compuational, Cálculo Integral, Estadística, Matemática Discreta, Física, Electrónica, Circuitos Digitales...
Otras no relacionadas directamente: Algoritmia, Transmisión de Datos, Control de Procesos, Modelado y Simulación, Robótica, varias de Lógica...

Personalmente prefiero este tipo de asignaturas a otras orientadas a gestión. De todas formas pienso que te equivocas en tu planteamiento, no porque una carrera tenga más o menos asignaturas de física o de matemáticas debe considerarse o no una ingeniería (aunque sí estoy de acuerdo en que debe haber una base sólida). Saber que la conductividad eléctrica del Silicio es X no le hace a uno mejor o peor ingeniero.

Para mí se debe considerar una ingeniería porque, a parte de la base, existen otras asginaturas donde también se deben resolver problemas, como por ejemplo sistemas concurrentes, inteligencia artificial, sistemas de tiempo real...ofreciendo soluciones eficientes a dichos problemas en base a unos recursos limitados. Esa es la idea que tengo de una ingeniería.

Ahí se ve si uno vale o no vale. Espero no equivocarme mucho. El saber hacer interfaces gráficas, pintar botones o cosas del estilo puede aprender cualquiera con más o menos tiempo.

Otra cosa es que luego acabemos casi todos de machacas...esto...quería decir programando en Java en alguna cárnica...empresa, perdón. Ya que en el mercado, la mayoría del trabajo esta orientada a la gestión de empleados, proveedores, patatas o lo que sea.

En cuanto al tema del foro, soy de los que opinan que se llame como se llame seguirá siendo lo mismo, para bien o para mal, por lo menos a nivel académico. A nivel laboral ya veremos lo que pasa.

Pues me parece un argumento bastante cojo... también hay infinitas maneras de diseñar un puente, un edificio, etc...

Según vas haciendo cosas más concretas, las posibilidades se reduce, pero es que para aguantar tal peso sobre tales apoyos, habrá menos opciones, pero también hay muchísimas... como pasa con la informática, que cuando más concreto es el problema, menos formas diferentes habrá para solucionarlo.

Pero vamos, no entiendo la relación entre cantidad de maneras diferentes de hacer algo y las conclusiones de la opinión.

No hay verdades absolutas en el software, como no las hay en la medicina, ni en la construcción, ni en absolutamente nada. Eso sí, hay cosas bien hechas y cosas mal hechas... y la calidad existe tanto en el software como en los edificios o en la atención médica.

Antes de nada quiero aclarar que a mí me es indiferente que me consideren ingeniero o licenciado. A mí lo que me importa es poder hacer buen software, ser reconocido por ello y ser pagado en consecuencia (ahora tengo que poner los pies en el suelo otra vez).

Entiendo que el SW no es una máquina, es intangible, se hace *una* vez y se copia a mansalva. Una máquina es material y eso tiene sus consecuencias de producción. Pero al final son soluciones a problemas, y los problemas se descomponen en problemas más pequeños, y así sucesivamente hasta resolver el total. Creo que al igual que un motor tiene piezas, el SW tiene sus piezas. Y creo que hay muchos motores distintos para un mismo fin, por ejemplo para mover los coches, basados eso sí en las mismas ideas. Como en el SW. El hecho de que el autor afirme que un proyecto de software tiene, virtualmente, infinitas soluciones correctas me parece un tanto hueco, porque es trasladable a cualquier solución a un problema complejo, ya se traduzca en un producto material o no. Y el hecho de que el SW pueda ser más flexible en este aspecto efectivamente dificulta las cosas, lo cual, debería tenerse en cuenta a la hora de valorarnos (dame pan y dime tonto, el nombre es lo de menos).

Evidentemente un analista/desarrollador puede tirarse horas complicando el código y haciendo auténticas gilipolleces con el flujo y creando infinidad de clases/módulos absurd@s... pero una cagada de diseño/implementación es una cagada, y suele ser de fácil argumentar sobre su mal olor. Así que eso de Y además existen infinitas implementaciones que pueden funcionar correctamente... venga... ¿¿a qué llamamos correctamente?? así nos luce el pelo.

No hay verdades absolutas en el desarrollo de software y eso complica los problemas. Cualquiera puede tener opinión, por absurda que sea, y sin embargo no existe una manera formal de rebatirla.
¿No hay verdades absolutas? diría que hay un puñado, para mí una importante es: hazlo bien desde el principio y así no cagarás fuego tú (u otro) en el futuro. Y me refiero a nivel de proyecto e incluso gestión, no a la implementación que lo doy por descontado. Otra podría ser: para hacer SW de calidad estima el tiempo bien. Lo sé, son banalidades pero son ciertas. Y en cuanto a que no existe una manera formal de rebatir las malas soluciones... pues, yo diría que sí. Al menos en la implementación no hay más que tirar de ciencias de la computación. Porque al final, y diría que esto no es en absoluto subjetivo, la informátia SÍ está apoyada en, como dice el autor, verdades matemáticas, en teoremas. Lógicamente no vamos a recurrir al análisis de algoritmos cuando estamos hasta el culo de trabajo y francamente poco valorados.

Y por cierto, si nos vamos a poner a relinchar sobre la pureza de la ingeniería mecánica, tendremos que señalar que esas matemáticas son indiscutibles dentro de su contexto formal pero que expresan ideas físicas, que muchas veces consisten en aproximaciones y que desde luego, no son ni mucho menos inmutables.

Si publicamos un libro empecemos por hablar con propiedad. O a hacer mejor las traducciones, porque por lo que he leído el señor Robert L. Glass da el perfil de persona que sabe de lo que habla.

Corregidme si me equivoco en algo, gracias.

Espero que ese párrafo sea el resultado de una mala traducción del libro " Facts and Fallacies of Software Engineering de Robert L. Glass" porque para empezar la frase mas incorrecta es:

"Un proyecto de software tiene, virtualmente, infinitas soluciones correctas"

Es 100% falsa, ya que un proyecto de software tiene solo una solución correcta, lo que hay infinitas son las formas de llegar a esta solución y las implementaciones que se realizan para conseguirla

"si tu calculas las dimensiones de una viga apoyada para que soporte una tonelada, tu solución si es correcta será idéntica a la del resto de ingenieros de este mundo."

¿estamos hablando de una viga diseñada para ser utilizado en el planeta tierra, bajo unas condiciones de estabilidad especificas, verdad? porque si estamos hablando de marte, la luna u otro planeta la cosa cambia, además si pasamos al mundo de la informática, dime si el hacer algo tan especifico como un hola mundo en determinado lenguaje, no tiene soluciones identicas al del resto del mundo.

"Además el proceso para 'desarrollar' una viga de una tonelada es exactamente el mismo que para desarrollar una de diez. "

El proceso para "desarrollar" un programa para una micro-empresa de forma correcta, es exactamente el mismo que para "desarrollar" el mismo programa para una multinacional.

Yo creo que es justo al contrario de lo que defiendes: para mi cuando la solución es única no hay una ingeniería. Por eso las matemáticas no son una ingeniería -y ojo, en matemáticas sí hay muchas veces muchas formas de llegar a un mismo resultado, pero en general el resultado es único-.

Para mi la ingeniería presenta precisamente esa incertidumbre, esa existencia de múltiples caminos y la necesidad de realizar un proceso de ingeniería previo a la exploración de dichos caminos. El trabajo del ingeniero es precisamente encontrar las distintas opciones (creatividad), descartar las inviables (objetividad) y determinar qué opción -o solución- es mejor y cual es peor (intuición, como forma de inteligencia, y no como un concepto paranormal), para elegir de entre todas la mejor.

Si solo hubiese una forma de hacer una biga, no hablaríamos de ingenieros de caminos, hablaríamos de constructores. El trabajo de ingeniería es descubrir nuevas formas mejores de hacer bigas y saber con una cierta certeza si van a funcionar o si se caería la casa.

En el software es algo parecido. El ingeniero no repite aplicaciones una y otra vez, sino que ingenia nuevas formas de resolver problemas existentes que sean mejores que las actuales.

Desde siempre en informática hemos hecho un especial hincapié en el ganchillo, el punto de cruz, los cuadros al oleo y el arte de la zambomba; asignaturas por las cuales sentimos una debilidad loca. Pero esta vez prometemos ser más aplicados en el futuro y quizás repasar las ecuaciones de segundo grado, la división con comitas a ambos lados y la teoría de patatas.

¿En vuestras facultades de informática que apasionantes temas tratais? Una vez escuché que en una hacían prácticas sexando pollitos.

"Que sea muy costoso no significa que no se pueda hacer."

Lo cuál demuestra lo poco de ingeniero que tienes. Las ingenierías tratan, precisamente, de lo que se puede hacer, no de otras calenturas de cabeza.

"He visto un video donde un puente se rompía en pedazos por los armónicos generados por el viento. El puente estaba perfectamente "ingeniado" pero ya ves, se vino abajo."

Ya... punto primero: se sabe perfectamente por qué se cayó y, precisamente por eso, se sabe que ese puente no estaba perfectamente "ingeniado". Punto segundo: ¿por qué te crees que has visto tú ese puente? Porque fue noticia. ¿Por qué no ves tú los cientos de proyectos de implantación de sistemas ERP que fracasan? Porque no son noticia. Ahora bien ¿por qué crees tú que una cosa es noticia y la otra no?

Sí, yo también dí el equivalente a esa asignatura (aunque bajo otro nombre) y precisamente nos avisaban de que hacer ese cálculo era prácticamente imposible en una aplicación medianamente decente. Ya no hablemos de algo grande como un SO.

La idea no es que hagamos un software (o hardware) perfecto, sino que podamos garantizar que al menos en un taitantos por ciento de los casos (¿80%? ¿90%?) va a funcionar correctamente. Para algo están los contratos software, yo te garantizo que esto va a rular, y si falla en algo, que te lo arreglo en menos de X tiempo. Si no cumplo mi contrato, entonces puedes demandarme.

La ingeniería informática está hoy en día como los coches de hace treinta años, te levantabas por las mañanas sin saber si ibas a poder llegar al trabajo o si tendrías que coger el autobus a toda prisa. Lo que queremos es cambiar esto ¿no? Y dar seguridad. Que no valga la excusa de "se me metió un virus" "el ordenador hizo cosas raras" para tapar otros errores. ¿Por qué le parece a todo el mundo tan normal que de pronto salte una excepción descontrolada y se reincie el ordenador?

Precisamente por eso tiene mayor relevancia que el resto la exigencia de responsabilidades

Si cualquier ingeniero de caminos hará siempre la misma estructura, eso significa que cualquiera que adquiera la formación similar a un ingeniero de camino podrá también hacer la misma estructura

.

Sin embargo, si un trabajo de ingeniería de software tiene múltiples soluciones, la verdadera labor de ingeniería es hacerla eficaz y eficiente (es decir, buscar la óptima).

Mayor complejidad en la búsqueda de soluciones (no hay una única), y mayor relevancia de la labor propiamiente ingenieril (de INGENIO)