#78 No, cobran entorno a unos 6000€ más IVA al mes, de ahí que les queden esos 4000€ limpios al mes.

#23 Puedes compararlo si asumes unas cuantas cosas. Hay 3 millones de personas en Madrid, con 3 personas por casa y el 20% de los pisos son de alquiler. Tienes 200.000 pisos de alquiler, con lo que un 7% de los pisos van a AirBnB. Si los pisos se alquilan de media cada 3 años y se quedan en idealista 2 meses tienes que debería haber unos 11.000 pisos en la página, así que los números son comparables.

En una ciudad como Amsterdam hay 11.000 pisos en AirBnB. Hay 800.000 personas, con 3 personas por casa y el 70% de los pisos son de alquiler (aunque muchos son de renta controlada y muchos de larga duración). Tienes 180.000 pisos de alquiler, un 6% de los pisos disponibles. En Amsterdam tienes que el casero no te puede echar ni subir el alquiler, por lo que los pisos se alquilan por muchos años y hay más presión sobre los pocos pisos disponibles.

#178 Felicidades por tu optimismo PSOEISTA

#66 Ya, si ganas 2.000 € al mes no es prohibitivo pagar 12 €, obviamente... y si ganásemos como Rafa Nadal que está todo el día diciendo lo bien que va España, tampoco.

Salu2

#21 Las especificaciones y los requisitos nunca son absolutos. No es posible definir todas las especificaciones de antemano porque solo las simulaciones, una vez creado el software, es capaz de detectar casuísticas no detectadas al principio.
Pero si quieres hablamos de las especificaciones y requisitos, seguro que hablan del "diseño de un sistema de control robusto". Si llaman robusto a decidir que estaba a 2km bajo tierra tras haber pasado un segundo desde el despliegue del paracaídas entonces hay un problema evidente de concepto. Aunque lo que creo es que ha habido un fallo evidente de testeo y de falta de simulación.

#23 What? En la industria espacial, los requisitos son absolutísimos. Al contrario que en desarrollo de software convencional, en esta industria, el cliente (normalmente el equipo de una misión) sabe mucho mas que el desarrollador en cuanto a lo que el producto debe hacer o no. De ellos depende definir con precisión los requisitos del software y los límites de lo que se considera una situación normal o no.

En cuanto al testeo y simulación, la misión exomars, al igual que cualquier otra pasa por un periodo de simulación no menor a 6 meses en el que todo el equipo (entre los que se incluyen miembros del "software support") actúa como si de la misión de verdad se tratase, recreando diversas etapas de la futura misión. Durante estos ensayos, el responsable de misión se dedica a "putear" al software y a los ingenieros introduciendo fallos a drede en los datos o incluso desconectando sistemas enteros. Todo este teatrillo tiene 2 objetivos principales: Entrenar a los ingenieros a actuar en situaciones fuera de lo normal y a detectar posibles fallos en los diferentes sistemas.

Si estados no válidos no han sido detectados, la responsabilidad primera deberá recaer sobre una mala ejecución de la simulación, después sobre una mala definición de requerimientos y en última instancia sobre el software desarrollado.

#30 ¿Quien ha dicho que los requisitos no son absolutísimos? No habrás visto salir esa afirmación por mi boca
Por ninguna parte leeras que haya escrito que GMV deba saltarse algun requisito.
Es cierto que existe un periodo de simulación de al menos 6 meses donde un conjunto de responsables de cada empresa implicada mas los responsables de mision se dedican a putear al software. Y es cierto que estos testeos no han demostrado ser suficientes. Estos tests son de conjunto y analizan comportamientos interrelacionados.
Sin embargo, y como bien sabrás, antes de estos testeos de conjunto cada empresa de software involucrada está obligada a someter a cada uno de sus programas a testeos unitarios para comprobar el correcto funcionamiento del mismo.
En este caso GMV debería haber realizado un testeo de su software(que supongo habrán logicamente hecho porque su contrato así lo requiere) y deberían haber detectado en los mismos un fallo tan crítico como la caída a plomo ante un fallo de uno de los sensores. Te recuerdo que el software encargado a GMV es el que toma la decisión de cortar motores tras un fallo en un sensor.
La unica cosa con la que no estoy de acuerdo contigo es que el cliente conozca mejor los requisitos que la propia GMV. O mejor dicho, estoy absolutamente de acuerdo que los requisitos definidos por el contratista son de obligatoria aplicación, pero es obligación de GMV de comprobar que son, además, suficientes y no entran en conflicto entre ellos para crear un control lo suficientemente robusto.
Supongamos varios escenarios posibles:
1) El contratista en los diagramas de flujo, requisitos, ha definido el comportamiento de como debe actuar el control robusto ante la señal del sistema inercial pero se le olvida definir que debe hacer ante el fallo del mismo.
Cuando el programador de GMV llega al punto de programar la respuesta del controlador detecta que el contratista no le ha definido este comportamiento ante señal anómala. Supongamos que entonces GMV entiende que al no definirle un comportamiento puede implementarlo como le de la gana. Y así lo hace. Cuando llegue el momento de realizar el testeo unitario(el testeo propio de GMV) al controlador, el testeo debe ser lo suficientemente amplio(intensivo y extensivo)como para comprobar que la decisión tomada por el controlador no lleva a pegarse un "vejigazo" contra el suelo. Probablemente además, aunque depende de los controles de calidad internos de GMV, el programador haya creado un test particular, red flag, para precisamente esta situación no definida contractualmente y así asegurar que el controlador funciona, ante esta situacion, correctamente.
En este caso a GMV se le puede achacar el hecho de que su decisión ha llevado al desastre de la misión y un testeo insuficiente.
2) Supongamos que GMV al programar el controlador se da cuenta de que existe este requisito necesario que el contratista no le ha dado. GMV que no es tonta y para cubrirse las espaldas le solicita al contratista que le defina como debe comportarse el controlador ante el fallo del sensor. El contratista le define un comportamiento que debe seguir y GMV lo implementa. GMV debería señalar este suceso con una bandera roja para que al realizar el testeo este caso se testeara a conciencia al ser un cambio a posteriori(los cuales son facil de que entren en conflicto con otros criterios ya implementados). Supongamos que ni contratista ni GMV se dan cuenta pero este cambio genera un desastre. Cuando llega a la fase de testeo interno de GMV, los tests que deben ser lo suficientemente intensivos y extensivos reflejan este desastre y se solicita un nuevo comportamiento al contratista.
En este caso GMV es culpable de no realizar los suficientes tests internos para detectar requisitos incoherentes.
3) A GMV se le pasa unos requisitos correctos de como se debe comportar el controlador ante el fallo del sensor inercial pero GMV lo implementa incorrectamente. GMV es culpable de un incorrecto desarrollo.
4) A GMV se le pasa unos requisitos correctos pero uno de ellos aunque definido desde el principio es incorrecto(el comportamiento ante señal anomala inercial). En este caso GMV deberia haber creado un test para esta situación ya que viene definida en los requisitos.
En este caso GMV es culpable de no haber desarrollado este test unitario ante comportamiento anómalo.

El unico caso en el que se salva GMV es en el caso de que GMV hubiese detectado en los tests este fallo y hubiese informado al contratista, el cual decidiese ignorar esta situación.

Te pondría enlaces a criterios de calidad, unit tests, normativa de proyectos, pero creo que te las sabes

¿Sabes lo que pasa? Que muchas veces el la creacion de tests se deja para el final, que a veces por ser lo ultimo y con el tiempo apremiante no son lo suficientemente extensivos, y que a veces se pueden saltar ciertoa criterios de calidad internos.

Obviamente la pelota se lanzará entre el que desarrolló la ingeniería de detalle, los requisitos y GMV. Y en ese embrollo se quedará todo.

De todas formas algo pasa en la ESA con sus tests y las de sus contratas porque en las uñtimas misiones han habido grandes cagadas en mayusculas que sencillos tests habrían detectado. Pero eso lo dejo para otro comentario.

#35 ¿Quien ha dicho que los requisitos no son absolutísimos?

Pues tú mismo en #23:
Las especificaciones y los requisitos nunca son absolutos.

De todos modos, yo no estoy tratando de exculpar a nadie. Sólo intento que se entienda que, en caso de un fallo en el software, existe una cadena de responsabilidad que hace que la "culpa" no recaiga directamente sobre el desarrollador.
Por eso, desanimaría a cualquiera a lanzar juicios culpabilizando directamente a GMV ya que, de momento, no existen datos que respalden esa teoría.

No hagamos sensacionalismo por favor.

#36 Creo que el resto de mi comentario de donde has extraido esa frase deja bastante claro a que me refiero con ese "absoluto". Donde reflejo precisamente que GMV no solo debe seguir las "absolutas" especificaciones sino detectar ademas requisitos que no se le han entregado y actuar en consecuencia. "Absoluto" desde la acepción de "entero, total, completo" de la RAE.
Los requisitos por propia definición son "de obligado cumplimiento por algo son requisitos. Es mas por ser requisitos deben ser ademas, segun la UNE 157001:2014 (si no recuerdo mal) coherentes, no ambiguos, concisos, alcanzables y verificables.
No voy a entrar a tirar de normativa, pero esto es como en los proyectos. Si yo a un constructor le doy los planos de una casa y se me olvida en la ingenieria de detalle decirle por donde debe pasar una bajante, el constructor que necesita de ese requisito para realizar su labor es obligacion suya contactar con el proyectista para que le resuelva un requisito no definido. El contratista no coge y dice, pued ea no hay bajante. De la misma manera si un requisito es incoherente con otro, aun siendo ambos "absolutos" (una bajante que corta a una tuberia de gas) el constructor es responsable de solicitar al proyectista las correcciones necesarias.
Sinceramente, conociendo como conozco los proyectos de software (y no, no hablo de hacer una app movil, con todo mi respeto a las apps moviles), GMV no puede entregar un controlador robusto(requisito fundamental seguro en el contrato) que corte los motores tras haber pasado tan solo un segundo desde la separación. Entre otras cosas porque un requisito debe ser verificable y creo que el proceso interno de verificación de GMV no ha detectado este fallo.
Sensacionalismo es soltar rebuznos por la boca sin argumentar y creo que mis comentarios están bastante argumentados.
Sensacionalismo es extraer una frase sacandole del resto de contexto, o simplemente definir como sensacionalista una opinion que estando argumentada es contraria a la deseada.
Ya me gustaría a mí leer una opinión defendiendo a GMV mínimamente argumentada.

#37 No te lo tomes a mal hombre, que no iba yo por ahí.

Sensacionalismo para mí es sacar conclusiones sobre algo a partir de información insuficiente.
Ahora mismo, con la información liberada, para ti y para mí nos es imposible saber si realmente la culpa fue de GMV o no. Lo único que podemos hacer es especular basandonos en nuestros conocimientos y experiencia.
No tengo nada en contra de especular, pero normalmente cuando yo lo hago, suelo usar fórmulas del estilo "Seguramente...", "A lo mejor...", "Yo opino...", etc. Sin embargo, tú en #19 catégoricamente declaras que la culpa es de GMV cuando realmente no lo sabes:

"Sinceramente. La culpa es de Gmv, la empresa española."

Para mí ese comentario va más allá de la mera especulación y cae en el sensacionalismo.

#21 Te doy la razón. Sin saber las especificaciones es difícil saber dónde esta la culpa. Si resulta que en esas especificaciones no se contemplan medidas de seguridad en caso de saturación de la unidad inercial... pues no le compete a la empresa de software decidir ponerlas porque sí... no son ellos quienes van a decidir cómo tiene que aterrizar la sonda.