2252
gallir.wordpress.com/2009/07/20/%C2%BFingenieria-del-soft... Los que leen habitualmente mi blog conocen mi opinión sobre la “ingeniería del software tradicional”, muchas veces hablé de ello y del “mal” que hacen en general a la profesión, hasta como limitan la innovación. Nunca me gusta que se llame “ingeniería” a un proceso que no tiene nada que ver con las ingenierías tradicionales. Pero ahora está surgiendo el mea culpa de los gurús incondicionales de la “ingeniería del software”, el reconocido gurú Tom DeMarco que escribió el artículo de opinión Ingeniería del software: ¿una idea de tiempos pasados?
menéame
-------------------------------------------------------------------------------------------------------
Estoy de acuerdo sobre todo en el tema del control de las aplicaciones y del valor real que tienen.
Esto es lo que les crea la fama de que "lo hacen porqué les gusta" y es que cuando deja de gustarles se van a otro sitio.
Una empresa no puede aprovechar un talento si poco después de formarlo se va de la empresa. No puede sacar un buen rendimiento económico si no puede contar con constancia y perseverancia a su vez que experiencia no solo en la tecnología sino en el entorno empresarial concreto.
Evidentemente que hay muchos ingenieros que no son así, a los que no solo les gusta su trabajo sino que además saben qué es un trabajo. Pero estos son los que no se quejan, los que ascienden, los que progresan. Los útiles.
Lo que no es normal (mi caso) es que te peles el culo haciendolo todo de puta madre, utilizando las tecnologias mas punteras, estandares, etc. y luego venga el comercial de turno y te tumbe toda la arquitectura porque "el cliente lo quiere asi".
Una vale, dos tambien, pero a la tercera que te lo hacen ya empiezas a mirar otras ofertas porque si hasta la limpiadora tiene mas peso que tú en el desarrollo de una aplicacion, mal vamos.
Lo que no entienden estos jefes es que si te vas, se acabo; te llevas todo contigo y un desarrollador nunca se puede reemplazar por otro.
Si lo que pide el cliente es técnicamente viable y económicamente rentable debe hacerse. No solo sin rechistar sino con una sonrisa de oreja a oreja.
El problema viene de creer que desarrollar es un arte. Los artistas son esos que se mueren de hambre en la calle y se les reconoce el talento cuando llevan 200 años muertos, los artistas hacen genialidades y después se pasan años sin producir nada de nada. Como comprenderás esto para una empresa no es rentable y el riesgo es demasiado alto.
El hecho que si tu te vas seas irreemplazable demuestra una muy mala gestión y poca profesionalidad. Tu desarrollo debería esta suficientemente organizado y documentado para que otro desarrollador pueda ponerse al día en un tiempo razonable. Y el jefe del proyecto debería controlar que eso sea así, si no hace ese control es tan culpable como el desarrollador.
Donde me chirria es en que el esfuerzo no puede ser medido, al menos en el entorno empresarial. Yo lo veo a mi alrededor todos los días cómo se mide y las fechas de entrega coinciden.
Teniendo en cuenta que la gran mayoría de aplicaciones empresariales se basan en frameworks más que conocidos (java + oracle, y sobre ésto hibernates, springs y struts de turno, con .NET tres cuartos de lo mismo, php, al menos se me ocurren 4 frameworks, y con python otros tantos, sistemas de BI, que si SAP...) no encuentro dónde no puede ser medido, o al menos estimado con un 10-20% de desviación. Claro que para ello hacen falta tecnólogos con experiencia y no gestores administrativos para dirigir a los equipos, que ahí es donde veo el fallo.
La sutil diferencia es cuando se va más allá, ya no digo crear un S.O., sino, por ejemplo, crear un framework nuevo, o un sistema de streaming (que hay APIs también, pero hay que crear el sistema), o un nuevo navegador... pero ésto entra en el I+D y, al menos en España, las empresas de "desarrollo empresarial" no suelen dedicarle demasiados esfuerzos.
Ahí sí es donde no vamos a poder medir el tiempo, pues cada línea de código es un experimento, y ahí es donde nos gustaría estar a muchos también
Es mi humilde opinión.
Eso de que el cliente siempre tiene la razon hay que cogerlo con pinzas.
Él asume los riesgos, ya sea conscientemente o por incompetencia, y él deberá asumir las consecuencias.
"Que quieres analogico? ruido, imagen doble y nieve? pues muy bien!"
www.youtube.com/watch?v=CgG6YPr8jus
Por mucho que se cambie el nick y el avatar, no puede engañar a todo el mundo todo el tiempo. Esta vez le hemos pillado con el carrito del helado.
¡Toma, toma negativo, tomaaaaa!
Hace un tiempo, no mucho, trabaje para informática del departamento de justicia de cataluña cuyos sistemas,como no, están diseñados por un equipo de ingenieros. Pues bien raro era el día en que no se cayeran 2 o 3 servidores(mantenidos casualmente por ingenieros) y rara era el mes en que no muriera la BBDD(diseñada también por un ingeniero) asi que con todo esto me da a mi que mientras nuestros ingenieros sean así miedo me da que desarrollen según el que.
Como puntualizacion, los mejores profesionales con los que he trabajado y de los que mas he aprendido no estaban titulados.
"El desarrollo de software es y será siempre algo experimental"
Acaso en ingenieria mecánica (por ejemplo) no es experimental. Vease: es.wikipedia.org/wiki/M%C3%A9todo_cient%C3%ADfico
Como que la ing. del software no se puede medir? No se puede medir la eficiencia de un programa? No se puede hacer un analisis de costes? No se puede analizar requisitos? Este tio es doctor en informática en serio?
"Muchos proyectos se han realizado sin demasiado control pero han generado productos maravillosos tales como Google Earth o la Wikipedia"
Oh brillante! sin demasiado control? Fruto de la casualidad? Como Meneame no?
Además, no me gusta el aspecto despectivo con el que se refiere a los "gurús" o "fanboys de la ingenieria"
El respeto y valor de la opinión se lo tiene que ganar uno, y me parece que Meneame no es suficiente (idea más simple que la Wikipedia, que ya existía, aunque no menos útil)
www.codinghorror.com/blog/archives/001288.html
Software Engineering: Dead?
"Tom DeMarco is one of the most deeply respected authority figures in the software industry, having coauthored the brilliant and seminal Peopleware as well as many other near-classic software project management books like Waltzing With Bears. For a guy of Tom's caliber, experience, and influence to come out and just flat out say that Software Engineering is Dead"
Aunque no es una traducción directa, la idea es la misma, al pobre Ricardo se le ve el plumero.
Todos tenemos "historias de horror", tanto de ingenieros como de no ingenieros. No demuestran nada, son casos particulares. Si queremos ser rigurosos con la ciencia, ya que precisamente hablamos de ello, deberíamos dejar de lado esas chiquilladas, un ejemplo concreto nunca ha servido para generalizar.
Así que de plagio nada.
Por otra parte, fantástico apunte, lastima que la frecuencia de actualización del blog haya bajado.
Supongamos un grupo de 6 personas para un proyecto que debería de durar de 6 meses a 1 año: la empresa le vende la moto al cliente y lo consigue en 2 meses, pruebas, corrección de errores y entrada en producción incluidas, por supuesto, ¿adivináis cuantas de esas seis son senior o con suficiente experiencia? pues solamente 1, el resto, para ahorrar costes, son gente que acaban de terminar la carrera, cero experiencia laboral pero con una mente "abierta" para currar y hacer más horas que el resto, fines de semana incluidos, ¡faltaría más!
A eso le unimos un comercial insulso, antipático y que todos los clientes detestan, con cero experiencia informática, "carnicero" como afición, ganando 3 veces más que tú (incentivos aparte), porque claro, encima les sale bien la broma, porque al final, el proyecto se acaba en tiempo, la gente es responsable y al final sale en esos dos meses... triste muy triste...
La correcta planificación de proyectos sigue siendo un tema pendiente en este país, el problema no son en los expertos, el problema surge más arriba...
www.codinghorror.com/blog/archives/001288.html
a ver si somos mas originales
Luego, despues de muchos años, si juntas a unos cuantos con mucha experiencia la ingeniería como muchos formalismos en otras áreas lo único que hacen es ralentizar el desarrollo.
Para programas de I+D+d o programas no típicos puede que sea mejor ir a tu bola, es indudable, pero si ya tienes uan experiencia.
Teniendo unos pasos concretos que seguir se aprende mucho más rapido, luego siempre hay tiempo de saltarse pasos.
Pero es que vamos, insinuar que sobra me parece ridículo.
Si a la creación de software no se le puede llamar ingeniería ¿como lo llamamos?. ¿Arte? Según el artículo debería ser así ya que no tenemos ninguna herramienta para crear el software, solo nuestra intuición y experiencia.
¿Cuenta eso?
El problema de elevar a arte el desarrollo de software como dice el Sr. Galli, es que aparecen pseudo-gurús-artistas diciendo que su arte es el mejor, y si no lo entiendes eres una analfabeto digital. Y no hay que irse demasiado lejos del citado autor para darse cuenta.
Ese producto simplemente está hecho a medida de tu cliente que lo usará para lo que le dé la gana. Eso si, no puede nunca obligarte a indicar que cumple tal o cual si no lo cumple. En ese caso estarías incurriendo en un posible delito.
Otra historia muy distinta es como presentas ese producto que has fabricado para ese cliente a tus otros clientes, evidentemente no puedes venderlo como que cumple tal normativa porque no la cumple.
Pero lo que hay que tener claro es que cuando fabricas un producto a medida ese producto no es tuyo, es del cliente.
Si eres una empresa de productos estándar que los vendes a distintos clientes entonces el cliente no tiene derecho a decirte como debe ser tu producto, solo puede sugerirlo y es la dirección de tu empresa quien decide si se hace de esa forma o no. Pero las capas bajas (de director para abajo) deben seguir las instrucciones de sus superiores (excepto si haciéndolo incurres en un delito, evidentemente).
Eso es a lo que comúnmente se le llama ser un trabajador asalariado.
Los que queráis ser artistas adelante, pero asumid las consecuencias de vuestra decisión.
Un diseño muy rígido y muy planificado limita muchísimo la creatividad y la innovación. Pero por otra parte, los usuarios quieren las aplicaciones para una fecha y sus recursos no son ilimitados. Así que un mínimo de planificación hay que hacer.
La cuestión es que muchos tipos de proyectos informáticos, y el que trabaja dia a día con clientes que se juegan el dinero y tiene fechas límite no tiene nada que ver con el que trabaja en una universidad o con el afortunado que está en el departamento de I+D de una empresa y tiene barra libre para probar ideas nuevas.
Aun así, lo cierto es que ultimamente noto que las nuevas hornadas de programadores apenas han oido hablar del concepto "diseño y programación estructurados".
Así que no entiendo la manía esa de decir que la Ingeniería Informática no es lo que se conoce como una ingeniería clásica...
Sobre #42 y estándares en el desarrollo de software. Haberlos, los hay, pero no son requeridos por ningún organismo. Como mucho, estar sujetos a la LOPD o a NDA de algún tipo, lo cual, al no requerir de una titulación especial dicha certificación, no sé hasta que punto puede considerarse como tal.
Como bien dice el artículo original, ciertos procesos pueden "ingenierizarse", pero en cualquier campo, en las partes de investigación, la parte de ingeniería es la menor de las partes. Sobre todo en informática. En ingeniería de estructuras, antes de ponerte a intentar fabricar a escala real un edificio horizontal, intentarás demostrar dicha posibilidad a través de un sistema de razonamiento (en ese caso física y matemáticas). Sin embargo en informática lo más parecido a un sistema de demostración razonable que tenemos es el diseño (UMLv2 habitualmente) o la simple demostración real (pruebas de código), siendo la más habitual, la última.
Yo no soy ingeniero titulado, todavía (el Grado EEES algún año caerá), trabajo en una empresa en el departamento de "ingeniería tecnológica", en proyectos de I+D. Los procesos están, más o menos, definidos. Se realizan análisis documental cuando se puede (aunque más tarde o más temprano siempre se asocian "notas" a la documentación), un diseño más grande o más pequeño y luego el desarrollo con su consiguiente memoria.
Cuando trabajas en una consultora no puedes esperar más que un trabajo en el que se usarán siempre un churro de tecnologías que vienen dadas por el comercial, porque venden y quedan bien en la oferta. Harás muchas más horas de las debidas, te pagarán poco y habrá que joderse. La solución la tenéis en la mano, dejad de trabajar para ellos, haced como hicieron otros. Buscad otro tipo de empresas de ing. de software, salid del país. Es fácil venir a meneame pidiendo la buaaambulancia, pero tenéis la solución en la palma de la mano.
Muy de acuerdo con la 2º parte, no tienes porque acabar en una cárnica haciendo paginas web's en php.
A lo que me refería con mi afirmación, es que no tienen validez legal. Sin embargo, si tú construyes un puente de estructura metálica, usarás unos pernos concretos, que puedan soportar el peso de dicha estructura, y esos pernos, legalmente, tienen unos requisitos que cumplir, lo que comunmente los mortales denominamos estándares. Desgraciadamente (o no tanto...) en informática no tenemos esos requisitos legales. El día que los haya, y con el consecuente esfuerzo que conllevan dichas certificaciones (tanto personal, temporal y económico) diremos adiós a muchos proyectos opensource.
Lo que empieza un poco a cansar es tanto los FPs con el tema de "he visto ingenieros que no sabían nah!!", como los ings de "los FPs sois unos picateclas" y luego todos a coro "mi jefe es un matemático!!!". De verdad, generalizar huele. He currado con un ingeniero superior con un año y poco de exp que era, como poco, retrasado. Curro con un ingeniero, actualmente, que es un jodido crack. Con FPs más o menos lo mismo. Y gente de fuera, pues no tengo el placer o la desgracia de conocer a ninguno.
A partir de ahí ya interviene la capacidad personal del programador para aportar una solución más o menos creativa. Lo que se busca es que un programador, basándose en toda su experiencia anterior, sepa cuánta cantidad de trabajo puede realizar, y sepa realizar estimaciones ajustadas a la realidad. Si el programador es muy disciplinado, puede llegar al mismo nivel que un programador muy creativo (un genio, vamos).
En cuanto al resto de ingenierías: ¿las métricas usadas en la construcción de edificios aseguran al 100% que este no se caiga? Vaaaaaya, parece que no. Pues con el software igual, aunque mayores, desde hace algunos años se está reduciendo drásticamente el porcentaje de proyectos que terminan en fracaso o fuera de plazo con sobrecostes, y cada vez más se ajustan con éxito a las necesidades iniciales del cliente. No me cabe duda de que dentro de poco este porcentaje crecerá.
Ya se sabe de dónde vienen todas las críticas a la informática como ciencia exacta, así que no me extraño de nada...
Alguien un poco puesto en calidad de software puede aclarar eso?
No está mal, pero las "buenas prácticas" no definen a las "ingenierías", ni son "ciencia". En realidad tampoco lo hacen por sí sólo los estándares ni las metodologías. Hay un error bastante extendido que el conocer o dominar metodologías y buenas prácticas nos convierten en ingenieros. Es sólo una parte, y no es ni de lejos la más difícil del aprendizaje de la profesión.
El marco actual es un sinsentido y un vivalavirgen que no preocupa hasta que algún día pase algo. Porque aquí siempre se legisla posteriori y nunca de forma preventiva.
CMMI te puede decir como va la construcción de tu edificio. Que las cañerías a partir del 5º piso pueden quedarse sin presión. Y que las paredes del piso 2º están mal levantadas. Pero no te va a ayudar en nada a proyectar el edificio; ni en como calcular pesos y poner las vigas maestras.
Sirve para que los jefes de proyecto tengan el ciclo de vida y la calidad bajo control. Pero no en el desarrollo propiamente dicho.
ingeniero: "Aquel que tiene por profesión trazar y ejecutar obras de construcción según principios científicos" ("El qui té per professió traçar i executar obres de construcció segons principis científics.", Diccionari Català-Valencià-Balear)
ingeniería: "Estudio y aplicación, por especialistas, de las diversas ramas de la tecnología." (DRAE)
Creo que mi trabajo cumple con estas definiciones. No veo diferencia entre el código de un programa y los planos de un edificio, excepto que en el caso de la informática los planos y el edificio son la misma cosa. Ahora bien, yo soy ingeniero informático, y nunca he sido ingeniero de ninguna otra clase, así que no sé nada de las otras ingenierías. Quizá me equivoco
1/que en el caso de la informática los planos y el edificio son la misma cosa.
2/que el cemento se agrieta, las piezas hay que llegar a ellas para cambiarlas... pero los while no se agrietan ni hay que cambiarlos. La informática está liberada de muchas restricciones del mundo real.
3/como la inteligencia es la misma y el camino es más llano, podemos liarnos a hacer cosas más complicadas.
Desarrollar un software complejo es difícil, pero aún lo es más estimar el esfuerzo que requiere ese desarrollo, y hacer que ese esfuerzo sea rentable; y ahí es donde entra la ingeniería del software.
De nada me sirve hablar de proyectos de software libre donde los recursos son ilimitados, donde no tienes un presupuesto limitado, ni unos plazos fijados por el cliente, ni una rentabilidad mínima esperada
¿Cuál hubiera sido el coste de GNU/Linux si hubiera que pagar las horas de trabajo de las miles de personas involucradas en el proyecto? ¿Hubiera sido menor ese coste si se hubieran utilizado metodologías de desarrollo más formales?
#59, #60: Efectivamente, esa es la diferencia principal: en informática, los planos y lo que hay que hacer son básicamente lo mismo. Precisamente por eso cuesta tanto especificar los programas, porque es tan costoso (o más) que picar el código, y a menudo se prefiere picar directamente para ahorrar ese enorme coste.
Básicamente depende del proyecto. A los jefes de la NASA, por ejemplo, no les vas a venir diciendo que el sofware de control del transbordador va a ser un programa "con vida propia", sin especificar.
Estoy tan cansado entre los que dicen que con Ingeniería del Software (I.S.) se resuelven todos los problemas, haciendo documento tras documento (tanto que ningún desarrollador tiene tiempo de leer) como con los que dicen que la I.S. no vale para nada, como parece que dice el artículo.
¿Que hay gente que no le gusta que se llame ingeniería? Estupendo, que lo llamen de otra forma, yo paso de tirarme discutiendo sobre las palabras más que sobre el significado, si todo el mundo entiende de lo que hablamos (no soy Stallman
La I.S. estudia y propone (propone) técnicas y herramientas para desarrollar un software más fiable. No busca la innovación, pero porque no es su cometido.
Si hacemos un software pequeño o entre una persona gran parte de lo que propone no son necesarios, no creo que nadie diga lo contrario (excepto los muy fanáticos que tiran por el MDA, Modern Driven Architecture, no me refiero a la droga
Lo que no se sostiene por ningún lado es el usar el Software Libre para comparar.
¿Qué en el software libre no hay documentación?
Es un problema en muchos casos, porque al final para entender algún software para poder entenderlo tienes que tirarte semanas (y meses) leyendo el código, interpretándolo y dando el 'coñazo' en las listas. Un poco más de documentación en muchos casos se echa en falta.
¿Y la comunicación? Las listas de correo, en casi cualquier proyecto hay mensajes y mensajes, que si dejas de participar debes de quitarte de la lista antes de ser saturado.
¿Y la coordinación? Debido a las restricciones (espaciales y temporales) se decibe en responsabilidades separadas, y la decisiones en la 'meritocracia'.
Y usar el software de Google como ejemplo de software sin I.S., puff, sin palabras.
(A no ser claro, que creamos que I.S. es lo que dice el 'gurú' de turno).
Sin acritud.
"Aunque estoy de acuerdo, no es lo mismo hacer un meneame, que un programa para el programa espacial de la NASA".
No es que meneame no tenga trabajo y sea una buena aplicación pero no deja de ser una web con AJAX+PHP?, o sea, nada especialmente sofisticado. Luego el tema de la escalabilidad a nivel de red es otro tema pero depende del hosting y demás. Tal vez no lo haya publicado por eso.
El éxito de meneame no es el software (que no se puede comparar al Kernel de Linux ni similares, ni a otros sistemas web parecidos. Y con una innovación existente, pero no exagerada) como para si no los usuarios que estan registrados en meneame.
(Más o menos)
Segundo; la ingeniería del software habla de procesos y de patrones conocidos; reinventar la rueda está muy bien si quieres aprender, pero no es ni útil, ni eficiente y precisamente ahonda en ese problema; no poder predecir los proyectos. Decir que la ingeniería del software no es útil porque "organiza" las cosas es ahondar en esa visión romántica de que el desarrollo de aplicaicones es un arte; y eso es un error; hay partes del desarrollo de un proyecto que dependen del ingenio; soluciones elegantes, algoritmos ingeniosos,... esas partes, son arte. Definir una arquitectura, organizar módulos, tener la especificación de requisitos, pensar en lo que vas a hacer antes de hacerlo... eso no se puede hacer así, a pinceladas. "Soy el vangogh de la programación".Por el santísimo MEV, vaya chorrada.
¿Las métricas? son útiles si previamente tienes todo montado; si no sabes qué quieres medir y para qué, de poco sirven.
¿Estimaciones? hacerlas de la nada no es factible. Antes ha de haber un proceso de recogida de requisitos, evaluación de viabilidad, decisión de tecnología y qué componentes se van a implementar y cuales se vana reutilizar...
Intentar que la ingeniería del software funcione cuando se tiene el concepto de que TODA la creación de software es creatividad e ingenio no es viable. Estoy de acuerdo en que sistemas como RUP son arcaicos, se crea demasiada documentaicón de escasa utilidad y en general, son ineficientes. Pero hay evoluciones y nuevas metodologías (las metodologías ágiles, por ejemplo) que son bastante útiles.