Login Barrapunto
¿Por qué es tan difícil desarrollar software de calidad en plazo?
editada por McPolu
el 21 de Noviembre 2006, 08:50h
desde el dept. Ingeniería-del-Software-para-todos
desde el dept. Ingeniería-del-Software-para-todos
Porque sólo construimos software que nunca ha sido construido antes. Al menos eso es lo que se afirma en Coding Horror , un excelente blog técnico.
Tras las ya tradicionales críticas al modelo de desarrollo en cascada y las recientes críticas al desarrollo ágil, el debate no se detiene. Si la informática no es ciencia ni ingeniería, y pensamos que programar no se parece a las matemáticas, entonces ¿a qué se parece el desarrollo de software? ¿Cómo podemos mejorar el proceso? ¿Surgirá una nueva metodología en el futuro?
Este hilo ha sido archivado.
No pueden publicarse nuevos comentarios.
¿Por qué es tan difícil desarrollar software de calidad en plazo?
|
Log in/Crear cuenta
| Top
| 50 comentarios
| Buscar hilo
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
Je,je,je
(Puntos:4, Inspirado)( http://barrapunto.com/~spike_mandrake/journal/ | Última bitácora: Jueves, 12 Junio de 2008, 10:30h )
Pues a mi me recuerda, tal y por lo que veo a mi alrededor, a las películas de naufragios. El agua (las necesidades y requerimientos de los usuarios finales) nos desborda y nosotros achicamos para no hundirmos (preparamos análisis acelerados, diseños técnicos chapuceros y picamos código a toda pastilla). Si tenemos suerte, achicamos suficiente agua para poder llegar medio hundidos a puerto y acabar las reparaciones (depurar y corregir errores con el programa-sistema ya implantado o en fase de ello).
El cambio climático se produce por la instalación masiva de Ubuntu
Si los albañiles fueran programadores
(Puntos:5, Divertido)Hoy me han llevado al solar por primera vez. La situación es perfecta: tiene el Metro a dos pasos y una cafetería enfrente donde sirven menú del día. El viejo bloque de pisos, al que va a sustituir nuestra nueva construcción, lleva un año al borde de la ruina. Mi propia empresa ha colocado varios puntales que, por el momento, han ido evitando que el caduco edificio reviente por sus múltiples grietas. La construcción de este megalito ladrillo comenzó hace cinco años, y aunque los pisos superiores nunca llegaron a recibir el agua, la electricidad y el enfoscado de las paredes, en diez meses los cimientos ya se habían desplazado peligrosamente y las vigas presentaban peligrosas fisuras. La cansada torre de viviendas ya ha cumplido su propósito y ahora nosotros la conduciremos a una muerte dulce... Por supuesto, el viejo edificio no será demolido hasta después de construir y probar el nuevo, lo que nos deja poco espacio de maniobra; pero no vamos a dejar a todas esas familias en la calle durante la construcción. De cualquier modo, los vecinos de la vieja y decadente estructura nos miran con recelo. Saben que el nuevo edificio tendrá viviendas cómodas, pero algunos de los residentes no podrán costearlas. Ni sé qué va a ser de gente, ni es asun-to mío. Llegan los primeros camiones de ladrillos.
* Dos de enero
Me han presentado a Alberto, la persona a quien "voy a reportar". No me han dicho si es el capataz, el jefe de obra, el aparejador, o el arquitecto; sólo me han dicho que todo lo que tenga que "reportar" se lo "reporte" a él. Así que, por donde él diga, yo zaca-zaca, como una locomotora. Esa es la definición que me han dado de nuestra metodología. He buscado "reportar" en el diccionario, y no aparece.
*Seis de febrero
En algo más de un mes, hemos cavado medio metro de cimientos. Ayer Alberto nos dijo que empezáramos a poner ladrillos, porque el tiempo designado para la cimentación se había agotado hace dos semanas. No aceptó nuestras excusas de que las prometidas excavadoras aún no habían llegado y que nos habíamos visto obligados a cavar con las paletas de enyesar. Un compañero se trajo un pala de cavar que guardaba de una obra anterior y casi le echan por razones deontológicas. Según Alberto, lo que pasa es que frecuentamos demasiado la cafetería. El asunto se ha zanjado con un "hale", a levantar paredes y luego que cada palo aguante su "vela". El trabajo sin planos es dificultoso. Los cimientos tienen una forma algo pintoresca. He pedido una plomada para que las paredes queden verticales y he recibido improperios poniendo en duda mi masculinidad. Ya sé que Alberto no es el arquitecto, porque el arquitecto es un tal Ignacio. Pasó a supervisar la obra el otro día. Aunque aún no había nada que ver. Me han llegado rumores, aunque no son muy dignos de crédito, de que existen fotocopias de planos.
* Doce de Mayo
Anoche estuvimos hasta la siete de la mañana cubriendo con tablas y enmoquetando el espacio que algún día ocupará el despacho de la planta, aunque el edificio no es aún más que una maraña de vigas de todos los tamaños y algunas paredes que habrá que tirar más tarde están en el sitio equivocado. Hemos traído baterías para los fluorescentes y unos muebles de caoba preciosos. Por suerte, todo estuvo a punto para la demo. Izamos al cliente con la grúa hasta su futuro despacho y pudo contemplar la vista que disfrutaría desde el emplazamiento. El viento hizo que la pared oeste, que dos de mis compañeros sujetaban con la espalda, se derrumbara con gran estruendo sobre la mesa de caoba en el peor momento. Gracias a Dios, el cliente fue comprensivo: esto pasa siempre en las demos, y él está curado de espanto, dijo mientras el sacudíamos el polvo del traje. Dice que el lunes que viene vendrá a probar las instalaciones sanitarias. Supliremos con cubos la inexistencia de tuberías.
* Veintitrés de febrero
Han transcurrido casi catorce meses. Llevamos ya siete de retraso y el edificio no acaba de superar el estado de "casi terminado". Soy de los pocos albañiles que no ha camb
Diferencia de idomas
(Puntos:2, Interesante)80% func. -> 30% del tiempo -> queda un 70% y habrá algún cambio sustancial en el diseño
90% func. -> 60% del tiempo -> queda un 40% y habrá que revisar todo el código
99% func. -> 85% del tiempo -> queda un 15% y haber si podemos encontrar ese error
100% func. -> 97% del tiempo -> queda un 3% para paquetizar y aún tienes documentar
120% func. -> has multiplicado x3 el tiempo estimado -> ¿ que estaba mal el análisis o el diseño ?
E como los pintores
(Puntos:2)( http://barrapunto.com/~puefale/bitacora | Última bitácora: Martes, 12 Agosto de 2008, 14:35h )
Es en definitiva lo que pasa en el mundo de la informática, que mucha gente se piensa que sabe informática por abrir el word, utilizar el emule e instalar un windowse... Después pasa lo que pasa, pero claro, como "los han educado así" no se extrañan que se cuelgue el sistema, que tengan que navegar con un programa determinado o el típico "es un error informático".
Hay que empezar a considerar la informática y la telemática como un bien básico, yo lo compararía con la red eléctrica, por una parte es cierto que hay muchos que hacen chapucillas, pero en temas de grandes infraestructuras se toma en serio el tema, y si las empresas fallan el gobierno interviene.
Pué fueno, pué fale, pué m'alegro.
Maquinavaja.
error, la pregunta esta mal formulada...
(Puntos:5, Inspirado)Solo hay una forma de desarrollar buen software, y es con tiempo, y buen hacer, muchas pruebas, y buenas arquitecturas, ademas de otros muchos factores. Cuando las maximas en la industria de desarrollo de software en España son:
- Lo queremos ya.
- Mañana hay que presentarlo, luego ya lo dejaremos bien.
- Es una chapuza pero es lo que hay.
- ¿Tan diferente es cobol de Java? (esto me lo dijo a la cara un director de proyecto)
- Va mas lento que el caballo del malo, pero va ¿no?.
- La cosa es meter la cabeza, luego ya le haremos bien las cosas.
- Si falla, podremos cobrarles por mantenimiento.
- Salvese quien pueda.
Poco mas que decir.
"a mas ver"
_mcready_
La complejidad
(Puntos:4, Inspirado)( http://yapw.blogspot.com/ | Última bitácora: Lunes, 18 Agosto de 2008, 06:51h )
Es una dedicación multidisciplinar, diría yo y tiene más matemática implícita de la que parece (Aparte de que sus fundamentos son matemáticos [auckland.ac.nz]) Además, hablando ya de su aplicación práctica entra en juego el control de la complejidad [wikipedia.org] (en mi opinión) como en ningún arte o ciencia hasta la fecha.
Por eso, entre otras cosas es diferente (y por lo mismo tan incomprendido...) Ya lo decía no obstante uno de los maestros, Brian Kernighan, que controlar la complejidad es la esencia de la programación de ordenadores [wikiquote.org] .
La nostalgia ya no es lo que era.
No es difícil
(Puntos:4, Interesante)( http://www.manje.net/ | Última bitácora: Martes, 03 Junio de 2008, 10:59h )
Si te dices que construyas una base de datos telefónica seguro que puedes planificarlo todo bien y entregarlo en el plazo correspondiente.
Yo creo que el software, con sus características, si es un proyecto de ingeniería, y vamos, que la construcción de autopistas pisos, etc. también se retrasa ¿o no?
-------------
Sin firma
El problema es sencillo
(Puntos:2, Interesante)Así de sencillo, con una mala (o incluso inexistente) planificación no se puede hacer un software ni siquiere medio decente.
La verdad está ahí fuera, ¡pero como corre la jodia!
¿Cómo podemos mejorar el proceso?
(Puntos:4, Interesante)Teniendo prácticas adecuadas [joelonsoftware.com] y siguiendo planes de trabajo [joelonsoftware.com] que se ajusten a la realidad.
Constructores de puentes (una divagación)
(Puntos:3, Inspirado)( http://barrapunto.com/ | Última bitácora: Martes, 17 Octubre de 2006, 07:20h )
Tengo la impresión de que la programación actual, con solo 40 años de vida, aún le queda camino para establecerse como ingeniería. Es demasiado volátil, con pocos estándares y prácticas recomendadas en comparación con otras industrias. Se vive demasiado al día, se reutiliza poco código y hay poco consenso en la utilización de las herramientas. Nótese por ejemplo el maremagno de lenguajes de script que sirven para lo mismo y que cuentan con acérrimos defensores de cada lado.
También hay que señalar la nula cultura ingenieril del sector. ¿Os imagináis a un licenciado en Empresariales dirigiendo el diseño de una nave industrial o el tendido de un ferrocarril? Pues es en informática muy usual que muchas decisiones de alto nivel las tomen personas con muy poca cualificación técnica.
En definitiva, actualmente la informática es una jungla, donde uno puede encontrar oro o ahogarse en el río. Con el tiempo esta profesión tenderá a parecerse a un prado, aburrido pero confortable.
P.D. Estoy firmemente a favor de los colegios profesionales y de la demarcación de competencias.
120 caracteres no son suficientes para escribir una firma con personalidad
Malos profesionales y punto
(Puntos:5, Inspirado)( http://barrapunto.com/ )
Yo flipo con las excusas de algunas de las paginas enlazadas: que si lado-izquierdo/lado-derecho del cerebro, que si programar por inspiracion divina mirando al techo....
Es cierto que en todo proyecto de software hay una parte de investigacion (= desarrollo propio), pero el impacto de esta parte se minimiza mucho si:
Creo que hoy en día el trabajo del desarrollador de software debe tener mucho más de integración de componentes que de desarrollo puro. Y si no es asi, es que estamos reinventando la rueda.
Por supuesto, un pryecto de software ES un proyecto de ingeniería, con sus requisitos, su diseño, su ejecución y sus pruebas. Y como cualquier proyecto de ingeniería, si se hace mal alguna de las partes, se convierte en un mal proyecto de ingeniería.
Bueno....
(Puntos:2, Interesante)En informática se puede hacer ciencia, se puede hacer ingeniería y se pueden hacer matemáticas. Otra cosa es que, efectivamente, el desarrollo de aplicaciones no sea ni ciencia ni ingeniería ni matemáticas. A lo que más se parece es a la ingeniería, desde luego, pero en la fase de diseño no en la de programación.
Respecto a lo de los plazos y la calidad, la respuesta es evidente. Por un lado tenemos plazos poco razonables: Los plazos no los pone el que diseña la aplicación, sino el que la vende (alguien que no es competente para estimar los plazos de desarrollo). Por el otro lado tenemos programadores que no saben programar: Es triste pero cierto, el 90% de la gente en una consultora NO SABE PROGRAMAR. Los que se sientan aludidos por ese 90%, que ni se molesten en responder rebotados: SOIS UNA LACRA. El otro 10% que tiene que hacer el trabajo de los demás, entenderá por qué estoy tan quemado a ese respecto. He pasado por tres consultoras y en todas el mismo cuento, gente que no distingue una método virtual de un atributo estático... y cosas peores, podría escribir un libro con las aberraciones que he visto y he oído en el trabajo.
Lo ideal...
(Puntos:1, Interesante)Evidentemente, acabo de decir algo similar a lo que diria la primera persona que se le ocurrio esto de los frameworks como Java y posteriormente
El futuro pasa por ahi, el que no lo quiera ver su problema es. Si usas clases prefabricadas que son de calidad y tu codigo es de calidad, el producto final es de calidad. Otra cosa es que seas un manoplas y consigas hacer un programa gracias a la facilidad de los entornos RAD pero luego funcione como el ojete, algo muy comun en muchas empresas que por ejemplo han pasado del VB6.0 al VB.NET pero sin aprender nada, es decir, directamente han pasado a aplicar lo que saben de VB6.0 a
El que lo quiera ver que lo vea, y el que no que siga con lo suyo. Pero a dia de hoy solo es rentable crear aplicaciones a medida con estas tecnologias.
Eso si, si vas a hacer un producto comercial
Salu2.
qué preguntas..
(Puntos:2, Interesante)( http://barrapunto.com/ | Última bitácora: Jueves, 15 Diciembre de 2005, 15:58h )
joder, qué preguntas a estas alturas, ni que fuéramos nuevos en esto ni ná...
La solución [lacoctelera.com] a qué es el desarrollo del sw, por qué tan baja calidad, plazos irreales, por qué no funciona ninguna metodología, etc. es bien sencilla... A ver, argumentos convincentes que refuten eso :-P
¿Puede ser porque se intenta vender como chorizo?
(Puntos:5, Inspirado)( http://barrapunto.com/ )
Por otro lado, la consultoría tenemos el siguiente proceso completo:
* Mediante mailing agresivo, llamadas de teléfono, etc. consiguen traer 4 personas a tu despacho.
* Cada una de ellas, como equipo perfectamente coordinado, dicen sí a todo, o queda pendiente de estudio.
* En reuniones posteriores, llega una tropa de funcionales extremadamente inteligentes que incluso saben con un sólo vistazo aumentarte la producción, las ventas, el rendimiento del almacén, etc.
* Comienzan a venir los técnicos. Armados con sus portátiles sólo realizan aquellas tareas que les encomiendan sus funcionales. Por lo tanto, tienes reuniones interminables porque el funcional tiene más claro que tú tu negocio.
* Ellos prueban sus desarrollos y al final del todo vienen y quieren que lo veas después de test y preproducción. Y cuando todavía estás asimilando los desarrollos comienza a oirse la palabra clave arranque.
* Si no acaba de satisfacer tus necesidades, la presión del tiempo, el arranque, que si son nuevas peticiones, etc, etc. hacen que al final te rindas a la evidencia: el único culpable eres tú: paga y calla.
* Al final tienes más o menos lo que has pedido, más un contrato de mantenimiento con ellos.
Y es que sale más rentable llevar cuanto antes la tropa al cliente que realizar un análisis de requisitos serio y profundo, ajustar tu desarrollo de software al ciclo de vida que pueda interesarle al cliente, integrar cuanto antes a usuarios designados por el cliente como testers y cuando se tienen todos esos documentos bien firmados y con responsabilidades garantizadas por la consultora hacerlo.
Creo que ninguna otra disciplina, exceptuando las operadoras de comunicación y el periodismo, pueden trabajar con tanta libertad para hacer lo que les de la gana sin control. Una obra está bien estructurada, un automóvil ha seguido un proceso muy controlado de producción, una butifarra igual. Un programa que imprime mis facturas no.
Se recoge lo que se siembra. Quizás sea momento de empezar a sembrar.
No somos más que muestras...
Lo mejor que he leido sobre este tema...
(Puntos:2, Inspirado)En un artículo titulado No les vamos a volver a engañar [geeks.ms], hace un excelente diagnostico de que es lo que pasa en está industría. En mi opinión imprescindible leer el artículo y el blog, si te preocupan los temas tratados en este hilo.
En general todo los etiquetado como opinión [geeks.ms] o gestión de proyectos [geeks.ms] en ese blog es digno de ser leido.
Lo de las metodologías ágiles
(Puntos:2, Informativo)