#0 A ver, porque yo como siempre me pierdo con algunas cosas...:
"Que haya fallos es normal", afirma, "lo que no es normal es que no se solucionen. Cada empresa que ha participado en Lexnet se ha encontrado con los fallos que traía la anterior. Ha faltado uniformidad: lo que la mayoría de empresas ha hecho es poner parches, en vez de solucionar los problemas de fondo."
¿Eso significaría rediseñar todo o casi todo el sistema desde cero y volver a picar el código correspondiente? Quiero decir, si es que son simples fallos de implementación o es que el sistema no hay por donde cogerlo y hay que empezar de nuevo.
Y luego dice esto:
""También se muestra crítico Epsilon, uno de los miembros del blog 'ingenio2010', que ha seguido de cerca los pasos de Lexnet: "Todo el mundo dice ahora que ha sido un 'error', pero es mucho más: es un problema de malos sistemas informáticos. Algunos de los fallos de Lexnet son de 1º de Ingeniería Informática y de 1º de Formación Profesional".
Además, tras los fallos de Lexnet, "el código está ahí fuera, cualquiera que sepa usar un buscador se lo ha podido bajar. Estoy seguro de que los problemas no se han solucionado."
¿Quiere esto decir que el código fuente no es "open" y se lo van pasando unas empresas a otras según convenga?
Y en cualquier caso... ¿Qué tiene que ver que "el código está ahí fuera" con la seguridad del sistema? ¿Le suena a alguien el concepto fallido de "security by obscurity"?
EDIT: Perdón, es "Security through obscurity", ¡puto idioma inglés de los cojones!
#1 Yo creo que deberían volverlo a hacer de nuevo... porque sé cómo van las chapuzas de las "cárnicas"... van haciendo y parcheando con becarios o ingenieros recién salidos de la carrera (o que ni tan siquiera han acabado) y al final tienen un monstruo que es una mierda de cuidado y no hay dios que sepa por dónde pillarlo. Seguro que es eso.
El código no creo que sea "open"... no sé a qué se refiere exactamente cuando dice eso de que "cualquiera se lo puede bajar".
Yo sobre todo he enviado el artículo por el primer tema que he comentado.
Sí, lo seguridad por ocultación es una gran kk que no funciona (ya que al final todo se acaba sabiendo).
#2 La idea es la de siempre:
1) Alguien licita el proyecto con una vaga idea de lo que quiere
2) Un gerente o socio se baja los pantalones y tira baja la oferta o directamente tiene información interna y se lo lleva calentito con un pliego a medida.
3) El gerente recorta en la fase funcional, y minimiza la fase de diseño. La consigna al project manager es: "tú haz lo que te piden, aprieta que hay que entregar en tal fecha y basta con que funcione, que en el mantenimiento está la pasta y así no palmamos por no entregar a tiempo".
4) Los curritos son fichados a precio de saldo, y vienen con el manual de programación bajo el brazo. El proyecto sale echando un sin fin de horas porque la gente coge experiencia a medida que va picando.
5) Hay rotación, gente que entra y sale, añaden más monos a picar módulos, se empieza a adivinar la chapuza porque ni hay consistencia, ni una arquitectura clara, ni está bien definida la funcionalidad desde el principio
6) Consiguen entregar alguna mierda que se sostiene por los pelos y que pasa a duras penas un juego de pruebas
7) Se monta una fiestaca por el "exito" y se pasa a la fase de mantenimiento, donde dejan dos pringaos para resolver la avalancha de problemas y marrones en el código debido a la sucesión de despropósitos durante la fase de diseño e implementación
8 ) Entramos en la fase actual donde hay un pufo de la hostia y no hay cojones de arreglarlo sin quemarlo todo y partir de cero.
#3 "La pasta está en el mantenimiento". Cuántas veces he visto esto... y así se hacen proyectos/productos de mierda.
La idiosincrasia "empresaurial" española tal cual. Qué puto asco. ASCO!
En lugar de trabajar para hacer bien las cosas, se hace mal para "enganchar" al cliente. Puaj.
Una vez me lo insinuaron en una entrevista de trabajo (como a principios del milenio) y huí despavorido de ese sitio.
*
"Que haya fallos es normal", afirma, "lo que no es normal es que no se solucionen. Cada empresa que ha participado en Lexnet se ha encontrado con los fallos que traía la anterior. Ha faltado uniformidad: lo que la mayoría de empresas ha hecho es poner parches, en vez de solucionar los problemas de fondo."
¿Eso significaría rediseñar todo o casi todo el sistema desde cero y volver a picar el código correspondiente? Quiero decir, si es que son simples fallos de implementación o es que el sistema no hay por donde cogerlo y hay que empezar de nuevo.
Y luego dice esto:
""También se muestra crítico Epsilon, uno de los miembros del blog 'ingenio2010', que ha seguido de cerca los pasos de Lexnet: "Todo el mundo dice ahora que ha sido un 'error', pero es mucho más: es un problema de malos sistemas informáticos. Algunos de los fallos de Lexnet son de 1º de Ingeniería Informática y de 1º de Formación Profesional".
Además, tras los fallos de Lexnet, "el código está ahí fuera, cualquiera que sepa usar un buscador se lo ha podido bajar. Estoy seguro de que los problemas no se han solucionado."
¿Quiere esto decir que el código fuente no es "open" y se lo van pasando unas empresas a otras según convenga?
Y en cualquier caso... ¿Qué tiene que ver que "el código está ahí fuera" con la seguridad del sistema? ¿Le suena a alguien el concepto fallido de "security by obscurity"?
EDIT: Perdón, es "Security through obscurity", ¡puto idioma inglés de los cojones!
El código no creo que sea "open"... no sé a qué se refiere exactamente cuando dice eso de que "cualquiera se lo puede bajar".
Yo sobre todo he enviado el artículo por el primer tema que he comentado.
Sí, lo seguridad por ocultación es una gran kk que no funciona (ya que al final todo se acaba sabiendo).
*
1) Alguien licita el proyecto con una vaga idea de lo que quiere
2) Un gerente o socio se baja los pantalones y tira baja la oferta o directamente tiene información interna y se lo lleva calentito con un pliego a medida.
3) El gerente recorta en la fase funcional, y minimiza la fase de diseño. La consigna al project manager es: "tú haz lo que te piden, aprieta que hay que entregar en tal fecha y basta con que funcione, que en el mantenimiento está la pasta y así no palmamos por no entregar a tiempo".
4) Los curritos son fichados a precio de saldo, y vienen con el manual de programación bajo el brazo. El proyecto sale echando un sin fin de horas porque la gente coge experiencia a medida que va picando.
5) Hay rotación, gente que entra y sale, añaden más monos a picar módulos, se empieza a adivinar la chapuza porque ni hay consistencia, ni una arquitectura clara, ni está bien definida la funcionalidad desde el principio
6) Consiguen entregar alguna mierda que se sostiene por los pelos y que pasa a duras penas un juego de pruebas
7) Se monta una fiestaca por el "exito" y se pasa a la fase de mantenimiento, donde dejan dos pringaos para resolver la avalancha de problemas y marrones en el código debido a la sucesión de despropósitos durante la fase de diseño e implementación
8 ) Entramos en la fase actual donde hay un pufo de la hostia y no hay cojones de arreglarlo sin quemarlo todo y partir de cero.
La idiosincrasia "empresaurial" española tal cual. Qué puto asco. ASCO!
En lugar de trabajar para hacer bien las cosas, se hace mal para "enganchar" al cliente. Puaj.
Una vez me lo insinuaron en una entrevista de trabajo (como a principios del milenio) y huí despavorido de ese sitio.
*