21/02/2006, 01:24
| ||||
| ||||
| Bueno en realidad los proyectos que queman son los que tienen fecha de entrega y millones de personas esperando el resultado ...
__________________ ¡Peron cumple, Evita dignifica! VIVA PERON CARAJO |
|
21/02/2006, 08:04
| ||||
| ||||
| Eso ya depende de lo que hagas, si es por seguir el ejemplo un software que controle un avion o un cohete la necesidad de eliminar los posibles bugs es enorme.
__________________ ¡Peron cumple, Evita dignifica! VIVA PERON CARAJO |
|
21/02/2006, 09:49
| ||||
| ||||
| Todos los proyectos de desarrollo grandes obedecen a un diagrama de Gant previamente elaborado... y (una vez mas) TODOS los proyectos de desarrollo nunca cumplen dicho diagrama. Pero como las barreras de salida son altas y ya el grupo que conforman el proyecto esta metido... la función debe continuar, hay proyectos que se atrasan con mucho tiempo, incluso años; y al cliente solo le toca aguantarse porque no puede botar al tacho lo que se ha venido haciendo durante todo el tiempo y empezar de nuevo. Allí vienen las renegociaciones, ya que tambien siempre pasa que los requerimientos del cliente cambian, generando cambios en el analisis y si es de mucho impacto obviamente se va a necesitar mas tiempo para realizar los cambios que se requieran, cosa que el jefe del proyecto tiene la escusa perfecta para justificar demoras. En la empresa que trabajaba antes, habían fines de semana que la gente se amanecía trabajando para entregar un producto a tiempo. Supuestamente y hasta en cierta medida eso es normal en las empresas de desarrollo. Cita:
Iniciado por Eternal Idol Eso ya depende de lo que hagas, si es por seguir el ejemplo un software que controle un avion o un cohete la necesidad de eliminar los posibles bugs es enorme. En produccion siempre existe un periodo de pruebas en el que corran el sistema anterior y el nuevo sistema en paralelo. Si existiese algun problema en el nuevo sistema, vuelve a desarrollo y no se pierde información |
|
21/02/2006, 10:18
| ||||
| ||||
| Cita: ¿De verdad? ¿Seguro? Mira las cosas que uno se viene a enterar ... por favor, las empresas de software tienen departamentos de calidad dedicados pura y exclusivamente a esa tarea: probar.
Iniciado por Developer9 En produccion siempre existe un periodo de pruebas en el que corran el sistema anterior y el nuevo sistema en paralelo. Cita: ¿Perder informacion? Sali de una vez de tu burbujita de bases de datos, no es el unico y gran "sistema" que todo el mundo escribe, en el ejemplo dado las perdidas serian humanas y no miseros datos.
Iniciado por Developer9 Si existiese algun problema en el nuevo sistema, vuelve a desarrollo y no se pierde información
__________________ ¡Peron cumple, Evita dignifica! VIVA PERON CARAJO |
|
21/02/2006, 17:07
| ||||
| ||||
| Cita: Creo que esto se llamaba riesgo del proyecto de sofware, y ahi se establecia el riesgo de que el producto falle. En un sistema de almacén el software NO DEBERIA fallar, en cambio en un avion, el software NO TIENE que fallar.
Iniciado por MaxExtreme Supongo que tendrá la misma "tensión" que por ejemplo una pieza de avión... Millones de personas lo usarán, y no debe de fallar. El software también cuenta. Bye
__________________ http://blog.tolaware.com.ar -> Blog de Java, Ruby y Linux |
|
22/02/2006, 00:14
| |||
| |||
| Cita: Aparte del sutil matiz lingüístico, ¿es que acaso podría fallar el de un almacén? ¿Quieres decir que si el software de un "almacén" falla... "Pues falló, y punto"?
Iniciado por TolaWare Creo que esto se llamaba riesgo del proyecto de sofware, y ahi se establecia el riesgo de que el producto falle. En un sistema de almacén el software NO DEBERIA fallar, en cambio en un avion, el software NO TIENE que fallar. Díselo a un banco, o a una cadena de hipermercados, a ver que te dicen si les gastas la broma de que el software que escribistes "ha fallado y punto", y ya no controlan la producción. O al kernel de un sistema operativo... Cada vez que se te ha colgado Windows (sobre todo los antiguos) y has perdido datos... ¿"Ha fallado y punto"? A mi me fastidiaba bastante perder horas de trabajo, y esto le ha ocurrido miles de veces. Lo mismo o peor en servidores... Diles que tu sistema puede o no fallar, depende. Cuando se les caiga la página web, me voy a reir... Tú eres de esos que aconsejarían instalar unos cuantos ordenadores porque se caen cada dos por tres. Sobre el avión... Imagínate el software que controle cualquier maquinaria pesada, o peor aún, el de armamento. No me gustaría que el ordenador tuviese un buffer overflow y empezase a tirar bombas a mi y a los demás, o lanzar una bomba atómica, que pete la CPU de navegación y vuele hacia arriba y caiga otra vez en el punto donde despegó... Realmente, el software importante simplemente "no puede" fallar. Mira si no AT&T... por un simple "break" en C colocado mal tiró más de la mitad de la red de telecomunicaciones de EE.UU. en su día. |
|
22/02/2006, 15:32
| ||||
| ||||
| Cita: En realidad me referia al impacto de la falla, no es lo mismo que una organizacion pierda 1.000.000 de dolares, contra la perdida de 250 vidas humanas.
Iniciado por MaxExtreme Aparte del sutil matiz lingüístico, ¿es que acaso podría fallar el de un almacén? ¿Quieres decir que si el software de un "almacén" falla... "Pues falló, y punto"? Díselo a un banco, o a una cadena de hipermercados, a ver que te dicen si les gastas la broma de que el software que escribistes "ha fallado y punto", y ya no controlan la producción. O al kernel de un sistema operativo... Cada vez que se te ha colgado Windows (sobre todo los antiguos) y has perdido datos... ¿"Ha fallado y punto"? A mi me fastidiaba bastante perder horas de trabajo, y esto le ha ocurrido miles de veces. Lo mismo o peor en servidores... Diles que tu sistema puede o no fallar, depende. Cuando se les caiga la página web, me voy a reir... Tú eres de esos que aconsejarían instalar unos cuantos ordenadores porque se caen cada dos por tres. Sobre el avión... Imagínate el software que controle cualquier maquinaria pesada, o peor aún, el de armamento. No me gustaría que el ordenador tuviese un buffer overflow y empezase a tirar bombas a mi y a los demás, o lanzar una bomba atómica, que pete la CPU de navegación y vuele hacia arriba y caiga otra vez en el punto donde despegó... Realmente, el software importante simplemente "no puede" fallar. Mira si no AT&T... por un simple "break" en C colocado mal tiró más de la mitad de la red de telecomunicaciones de EE.UU. en su día. Bye
__________________ http://blog.tolaware.com.ar -> Blog de Java, Ruby y Linux |
|
24/02/2006, 10:37
| ||||
| ||||
| Claro, en Ing. de Software se cuantifica el riesgo del proyecto y su impacto. Lo que se pierde si se cae el sistema no deja de ser dinero, que en realidad no es tan importante como la vida humana pero es igual de importante para la gente que puso el capital para desarrollar el proyecto y lo utiliza para su producción |
