El diseñador entra en fase de trance y habla de multi-abstracción, parametrización, multi-capas, paradigmas de diseño, diagramas de secuencia/estados/clases/el que se le ocurrió a alguien de alguna universidad USA/, vista/control, observador/observable, expresiones regulares, cronogramas detallando cada tarea, uso de recursos, CMM version 1,2,3,4,N, estandares de desarrollo, multiportabilidad y nada termina hasta que todo ese material impreso no ocupe varias estanterias. Pasan bastantes meses y cuando deciden programar nadie entiende ni un pimiento lo que hizo el diseñador.
La maquina de desarrollo funciona con Windows 95 y el antivirus ocupa 95% de la CPU.
Pasados 70% del plazo de entrega todavía no se habían entregado al equipo las maquinas de desarrollo.
El equipo presupuestado eran 3 analistas, el equipo real 3 becarios sin experiencia, dos de ellos sin siquiera formación académica en TIC.
Las especificaciones redactadas ayer se cambian hoy.
Las reuniones se marcan a partir de las 19 y duran más de tres horas.
Viernes por la tarde, hay que interconectar un ROBOT a un scada, nadie tiene la clave para acceder al scada.
Un responsable del cliente no quiere darte la documentación porque no esta de acuerdo en que se desarrolle el proyecto.
Un responsable del cliente no quiere darte la documentación porque no es su equipo quien lidera el proyecto.
El “responsable” de informática del cliente dice que tus fuentes son una “castaña” porque están en c++ y el no consigue compilarlos en turbo pascal (si hace años de esto)
El administrador del sistema no quiere darte privilegios de poder instalar ningún software en los equipos (tu desarrollo es un programa Windows instalable con Install Shield)
El administrador de red no quiere dar conexión a Internet al equipo de desarrollo, tu desarrollo es JAVA, y quieres poder conectarte a sun
El equipo de ventas dice a todo que SIIIIIIII
El cliente aprieta, pide cambios de ultima hora, el gerente dice AMEN, el JP recuerda que la base de datos no es un cubo y que la minería de datos no estaba presupuestada, es tachado de incompetente y defenestrado.
El ingeniero de software específico que los procesos que corren en el servidor estén hechos en C++, el analista no tiene a ningún experto en C++, los realizan en Visual Basic, el sistema se colapsa al entrar el tercer cliente simultáneo.
Comentarios
#1, el artículo aclara que sólo tradujo algunas de las 101 originales (en inglés) http://www.codesqueeze.com/101-ways-to-know-your-software-project-is-doomed/
De todas formas, tienes parte de razón, el artículo original debería estar aunque sea en la entradilla
El diseñador entra en fase de trance y habla de multi-abstracción, parametrización, multi-capas, paradigmas de diseño, diagramas de secuencia/estados/clases/el que se le ocurrió a alguien de alguna universidad USA/, vista/control, observador/observable, expresiones regulares, cronogramas detallando cada tarea, uso de recursos, CMM version 1,2,3,4,N, estandares de desarrollo, multiportabilidad y nada termina hasta que todo ese material impreso no ocupe varias estanterias. Pasan bastantes meses y cuando deciden programar nadie entiende ni un pimiento lo que hizo el diseñador.
Más hechos reales:
La maquina de desarrollo funciona con Windows 95 y el antivirus ocupa 95% de la CPU.
Pasados 70% del plazo de entrega todavía no se habían entregado al equipo las maquinas de desarrollo.
El equipo presupuestado eran 3 analistas, el equipo real 3 becarios sin experiencia, dos de ellos sin siquiera formación académica en TIC.
Las especificaciones redactadas ayer se cambian hoy.
Las reuniones se marcan a partir de las 19 y duran más de tres horas.
Viernes por la tarde, hay que interconectar un ROBOT a un scada, nadie tiene la clave para acceder al scada.
Un responsable del cliente no quiere darte la documentación porque no esta de acuerdo en que se desarrolle el proyecto.
Un responsable del cliente no quiere darte la documentación porque no es su equipo quien lidera el proyecto.
El “responsable” de informática del cliente dice que tus fuentes son una “castaña” porque están en c++ y el no consigue compilarlos en turbo pascal (si hace años de esto)
El administrador del sistema no quiere darte privilegios de poder instalar ningún software en los equipos (tu desarrollo es un programa Windows instalable con Install Shield)
El administrador de red no quiere dar conexión a Internet al equipo de desarrollo, tu desarrollo es JAVA, y quieres poder conectarte a sun
#8 Gracias por darle la razón a #7 y ponerme un negativo diciendo lo mismo.
El equipo de ventas dice a todo que SIIIIIIII
El cliente aprieta, pide cambios de ultima hora, el gerente dice AMEN, el JP recuerda que la base de datos no es un cubo y que la minería de datos no estaba presupuestada, es tachado de incompetente y defenestrado.
El ingeniero de software específico que los procesos que corren en el servidor estén hechos en C++, el analista no tiene a ningún experto en C++, los realizan en Visual Basic, el sistema se colapsa al entrar el tercer cliente simultáneo.
#7, gracias por la aclaración. Como dices, quizás tenía que haberlo explicado en la descripción de la noticia
#1, pues va a ser que yo NO te he puesto ningún negativo...
Yo añadiría otro más: El gestor de versiones es SourceSafe y el IDE de desarrollo VisualStudio 6 (también basado en hechos reales en pleno año 2008)
[Editado]
Es errónea...Faltan 86 motivos según el titular son 101 y solo he podido leer 15. (en la versión original que pone en la noticia si que hay 101).