La crisis del software

Publicado el by Fernando 14 Mayo, 2005 | Programación, Sociedad

“El software está en crisis”. A los que nos dedicamos a la informática esto nos suena a tópico, es algo que hemos oído en la carrera y hemos ido leyendo a lo largo de muchos años en multitud de lugares. Además, es algo en lo que todos están de acuerdo y que aún no se ha arreglado, ni tiene pinta de arreglarse en los años venideros.

Pero, ¿qué es la crisis del software? Este término fue acuñado ya en los años 70, cuando la industría del software ya había producido los suficientes programas para darse cuenta de que había algo que fallaba. En concreto estas eran sus principales inquietudes:

¿Por qué lleva tanto tiempo terminar los programas?
¿Por qué es tan elevado el coste?
¿Por qué no podemos encontrar todos los errores antes de entregar el software a nuestros clientes?
¿Por qué es tan difícil constatar el progreso durante el desarrollo?
¿Por qué es tan difícil calcular cuánto tiempo va a costar?

Esto pasaba entonces y pasa ahora, y por eso se dice que el software está en crisis. Ante dicha situación se planteó el aplicar métodos científicos y rigurosos al proceso de desarrollo de programas, apareciendo en escena la Ingeniería del Software y la Ingeniería de Requerimientos. ¿Han solucionado el problema? No, pero algo han aportado. Ahora lo mejor que sabemos hacer para afrontar de forma seria el desarrollo de una aplicación es análisis y requisitos + programación + ciclo de pruebas. Y esto funciona, pero tiene dos inconvenientes: el primero es que es muy difícil hacer un buen análisis que sepa abarcar todas las necesidades del cliente antes de que éste vea el producto final (entre otras cosas porque el cliente no sabe lo que quiere); el segundo es que nadie hace el esfuerzo de analizar y especificar requisitos, teniendo dicha parte el menor peso específico dentro de todo el desarrollo.

Una de las formas de abordar el primer problema son las consultoras enfocadas al usuario. Una de ellas es The Cocktail, y cito literalmente un fragmento de su web en el que explican una de las cosas que hacen:

es decir, conseguimos que el usuario se entere de qué va el servicio, qué puede hacer y cómo. Para que lo haga lo mejor posible.

que no es poco.

Si el cliente tiene claro qué quiere, interferirá mucho menos en el proceso de desarrollo obligando a cambiar aspectos que ya habían sido combenidos previamente. Y, aún así, a pesar de todo, lo hará.

Decía un profesor mío de Ingeniera del Software:

“El software no está en crisis, menuda tontería. La crisis le viene desde que nació. Lo que hay que plantearse es por qué no ha salido de esa crisis en todo este tiempo.“

Y creo que tiene razón.

Más información: Software crisis en la Wikipedia.

15 Comentarios en “La crisis del software”

Feed de este post Dirección para el Trackback Envía este post

1 Henry Gomez 23 Ago, 2006 a las 4:20 am

Muy interesante este articulo.Yo creo que el mayor problemas es que los clientes como tu dices “no saben lo que quieren”, pero sobre todo no se involucran en el proyecto es decir no le dan importancia a su propiom proyecto, piensan que solo deben recibir el producto final y ya esta, pero no es asi, ellos forman parte principal del proyecto , pues son concienntes de eso y no quien tomar CONCIENCIA.
2 adriana chalarca 2 Feb, 2007 a las 5:39 pm

es verdad lo que dice aquel profesor la forma no es criticar que esta en crisis si no aportar ideas para dar solucion a cierta crisis
3 Flor 21 Feb, 2007 a las 12:03 am

hola, buenas tardes
solo una duda que tengo necesito saber a que se debe esta crisis de software?
4 eduardo 22 Feb, 2007 a las 10:12 am

Considero que actualmente los nuevos sistemas de información son costosos en tiempos y recursos, la solución moderna de los actuales sistemas exigen nuevas herramientas y metodologías para poderlos resolver, de forma rápida, económica y eficiente los problemas de información planteados por algunas empresas.

Debemos de reconocer los problemas y causas para llegar a solucionarlos, mediante la combinación de métodos completos para todas las fases del desarrollo del software con ayuda de todas las tecnicas que actualmete existen como la re-ingenieria de software, la porgramacion orientada a objetos y lo que es UML inclusive el uso de Herramnietas CASE

y es cierto, eso.. que a menudo los usuarios no suelen ser realistas hasta donde quieren que su software sea realmente fucional hay situaciones que las modificaciones que solicitan o nuevas aplicaiones que requieren su elenser redundantes detro del mismo software…. eso y la mala costrumbre de hacer prugramas con la tecnica de prueba y error, hacen que sean mayores los consumios.
5 Eduardo 27 Feb, 2007 a las 4:56 pm

Muy interesante tu trabajo, creo que la principal razon por la que el software esta en crisis es por que al cliente no le importa en lo mas minimo el procedimiento para obtener un producto eficaz, simplemente se enfrasca en tener resultados sin siquiera detenerse a pensar en que es lo que realmente espera de dicho sistema…….Gracias..Colombia
6 Legui 1 Abr, 2007 a las 3:30 am

La crisis del software no se ha solucionado ni con máquinas más poderosas ni con técnicas de desarrollo más avanzadas ni con más cantidad de gente dedicada.

Pero “curiosamente”, la mayor demanda no ha redundado en la misma proporción en una “mejor valorización” de los informáticos en promedio, sino todo lo contrario.

Esta devaluación tiene una posible explicación que no por sencilla es menos contundente y penosa.

Hace poco hablaba con un conocido acerca de que para alguien con toda la expectativa y entusiasmo que suele otorgar la juventud, que estudia una carrera informática, por corta o supercompleta que fuera, y después se dedica a trabajar (o como solemos decir, “cae en un laburo”) como desarrollador, se está convirtiendo en una constante que sus frustraciones de a poco van superando a sus expectativas y debilitando sus esperanzas en comparación con el esfuerzo y la inversión personales hechos durante años.

En resumen, las promesas de ser un informático -al menos en algunas áreas “tradicionales”- ya no son lo que solían, si alguna vez lo fueron.

No precisamente porque a un informático promedio le vaya horriblemente mal en el contexto de la sociedad sino porque (y quizás es peor) llega a un punto después de un tiempo en el métier en que compara sus ingresos con los de otros puestos, que fuera de toda duda son absolutamente dignos y necesarios, y llega a conclusiones preocupantes del estilo “creo que no gano el triple de lo que gana el portero del edificio donde vivo”.

Esta odiosa comparación tiene, sin embargo, muchas implicaciones sociales.

Es más frecuente de lo que parece que a un informático dedicado al desarrollo de software, le surjan preguntas acerca de si los demás comprenden cabalmente qué es lo que hace para ganarse la vida. En realidad lo que sucede es que mientras no es muy difícil para la generalidad de la gente entender e incluso tener una idea cabal lo que implica el trabajo de un portero, es mucho más difícil para el común de las personas -que por vocación no se consustanciaron desde la raíz con la informática- hacerse una composición de lugar del informático con el mismo grado de calidad que tienen sobre el portero.

Entonces viene la gran pregunta: ¿ qué se entiende en general por “desarrollo de software” ?

Más concretamente, ¿ qué entienden por informática y por informáticos las personas que no han tenido la vocación o invertido parte de su vida en aprender y asimilar esta profesión ?

Incluso los cuadros destinados a tomar decisiones en áreas informáticas, ¿ qué entienden por desarrollar software ?

Y todo partiendo de que “aprender informática”, si bien tiene bases que incluso muchos que empiezan a hacer la carrera, llegado cierto punto ni se imaginaban a qué se metían, es una tarea constante porque está en cambio constante: nunca se termina de “aprender informática”.

A esta altura los informáticos ya saben que hay una tendencia a devaluar su trabajo, afectando la “calidad de su vida profesional” y por consiguiente las expectativas de desarrollo personal.

Y esa tendencia se debe, sin dudas entre otras razones, a una carencia de “consustanciación con las bases teóricas de la informática” del común de las personas. Incluso se verifica entre personas que durante años bien pueden estar relacionadas a tareas informáticas en sus respectivas áreas de trabajo, pero que como no han hecho de ella su vocación ni una carrera, no aprenden después lo que primero debe ser aprendido, valga la aparente redundancia, y por eso es natural que durante sus desempeños profesionales no se muestren inclinados a que sus acciones y decisiones tomen por caminos con los que evidentemente no se identifican.

El informático promedio, tarde o temprano, experimenta un cierto grado de incomunicación con aquellas personas, que incluso pueden ser compañeros de trabajo afectados tangencialmente al área, que carecen de esa consustanciación, de esa “absorción primaria de la cosa vocacional”, de esas primeras “lecciones” que desde el vamos “permiten a la psiquis separar” la ciencia de manejar la información con los medios físicos utilizados o el “dominio de los problemas” a ser “tratados informáticamente”.

Esa carencia se traduce en un visión diferente de las cosas, sobre todo de cómo encararlas y de cómo distribuir los pesos al momento de materializar un proyecto (y con “pesos” no me refiero a la unidad monetaria, aunque también se aplica…).

Es clásico que un profesional informático sea habitualmente confundido con el técnico que repara o arma y desarma la computadora. Algo así como yo podría confundir un piloto de autos de carrera con el mecánico. O al bibliotecario con un erudito en literatura.

Es una tendencia generalizada creer que un informático, además de informática, debe saber aunque sea un poquito acerca del dominio del problema para el cual tiene que desarrollar una determinada aplicación. O creer que “como le da la cabeza, no le cuesta nada aprender lo que sea necesario” del dominio del problema.

Pero es erróneo creer que esto reemplaza los pasos necesarios del desarrollo de software.

Un breve ejemplo con el que los analistas y programadores no tardan en identificarse: el caso del programador John Doe en un suburbio de Manhattan a quien de pronto la empresa de la que es empleado le comunica -como si se tratara de un trabajo de artesanía- que “prepare la cabeza y los materiales” para hacer lo más rápido posible un sistema de software completo para el observatorio astronómico que acaba de inaugurar una universidad en Bronxville. De pronto John Doe se ve enfrentado a la posibilidad de que sus empleadores crean que “él adquirirá sin dudas todo el conocimiento necesario sobre astronomía” para desarrollar el sistema.

El programador John Doe no sabe nada de astronomía ni debe saberlo ni la astronomía le mueve un pelo, pero es más frecuente de lo que parece que se espere que los diversos John Doe del mundo “de todos modos deberán saber algo de astronomía” para cumplir con el trabajo.

En realidad, todo lo que debe saber John Doe no es astronomía sino entender bien las especificaciones formales de análisis y diseño que le pasen los analistas y diseñadores. E interactuar bien con ellos.

Y todo lo que deben hacer bien los analistas y diseñadores es entender las especificaciones recogidas por los relevadores, e interactuar bien con éstos.

Y todo lo que deben hacer los relevadores es entender bien “las necesidades informáticas” del observatorio de astronomía, interpretándolas en términos de cliente y saber transmitirlas en términos informáticos a los analistas y diseñadores.

Si la cadena no fuera así, a los pobres informáticos (y me refiero sobre todo a los eslabones informáticos encargados de lidiar con la “cuestión física” de llevar a la práctica lo analizado y diseñado, no tanto a los cuadros superiores que en muchas empresas toman decisiones creyendo saber de informática y que irónicamente suelen terminar perjudicando con sus decisiones a los verdaderos informáticos) se les debería pagar sumas colosales de dinero, ya que supuestamente “deberían saber de medicina, agronomía, arquitectura, astronomía, terminales de autobuses, filatelia, banking, aeropuertos, shoppings, etc. etc.”.

Por lo tanto -además de todo lo que ya les implica a los programadores sus necesidades de actualización de técnicas y ambientes de desarrollo- tendrían que estar invirtiendo constantemente en su educación un aprendizaje aunque sea mínimo de cada dominio de problema a ser resuelto informáticamente.

Cualquier alumno promedio de una carrera informática, tarde o temprano se entera que no es el conocimiento del dominio del problema lo que aporta lo necesario para desarrollar software, sino lo que resulta de aplicar ténicas de desarrollo de software al dominio del problema.

Lamentablemente la experiencia marca que no sólo no se les paga sumas colosales a los desarrolladores sino que lo más frecuente es que los verdaderos informáticos no son los que se llevan la parte más interesante de la torta.

Esta experiencia revela que existen cuadros en las áreas informáticas que parecen preferir seguir desconociendo, aún sabiendo que alguna parte de la cadena siempre terminará pagando un alto precio (lo cual es una decepción en términos éticos), que “informatizar” básicamente es “primero entender las necesidades reales del cliente, luego traducirlas con claridad y sin ambigüedades a técnicas informáticas probadas, después es modelar el problema real y una aparente solución en un dominio informático, después es probar y confrontar con el cliente el modelo para saber si el mismo y su solución es correcta y recién después es empezar a fabricar algo en el mundo de las máquinas”, lo cual ya de por sí trae sus propios y abundantes dolores de cabeza.

Por lo tanto, si ya desde el relevamiento se prefiere saltear la construcción de los imprescindibles puntos de apoyo del puente entre el problema real y el modelo informático, entonces no debería sorprender que terminan saltando los eslabones de la cadena que sostienen el puente.

Para tratar de suplir esta carencia, de la cual los cuadros se dan cuenta, suelen sugerir que “sería interesante y nunca está de más” un acercamiento al dominio del problema del cliente de parte de los informáticos involucrados en la cadena de desarrollo.

El de esos cuadros es un razonamiento del estilo “como aquí nadie entiende ni interesa demasiado entender lo que dicen necesitar los desarrolladores, sino que lo que interesa es dejar rápidamente satisfechos a nuestros clientes, nos llevamos a los desarrolladores al terreno de
los clientes todo lo que podamos.”

Lamentablemente eso no produce por generación espontánea lo que los desarrolladores necesitan. Lo que se obtiene son John Does que además de informática salen sabiendo algo de astronomía…

Pero en cuanto a desarrollar el software puntual que el cliente mismo la mayoría de las veces no sabía que era lo que necesitaba…

Habría que preguntarles a esos cuadros por qué los mecánicos no se lucen haciendo de pilotos en las carreras de Fórmula 1, siendo que así ganarían mucho más. O por qué los pilotos no se ponen de mecánicos siendo que saben mejor que nadie lo que da el auto. O por qué los jugadores de fútbol no son los que mejoran el diseño de la pelota o las zapatillas, etc. etc.

Obviamente, sería tonto dudar del aporte inestimable de los pilotos para que el constructor de autos mejore su diseño. O de las experiencias de los futbolistas para que los fabricantes hagan mejores pelotas y zapatillas.
Obviamente que en el mundo real hay una dialéctica entre el pilotaje y la mecánica, entre el jugador de fútbol y la industria de los útiles deportivos, etc., pero siguen siendo entidades separadas y diferenciables. Que estén dialécticamente ligadas no implica en absoluto que estén mezcladas.

En informática, la desestimación de estos puntos de apoyo es lo que conduce generalmente a construir un mal puente y por lo tanto al desastre. O a un puente inadecuado o muy lentamente construido. Y el desastre es mayor cuanto más grande “se espera que sea el tránsito”, ya que es sobre esos pilares sobre los cuales se tiene que levantar ese puente que comunica “el universo del dominio del problema” con “el dominio informático”.

Lo que generalmente revela esta confusión, sin la menor piedad, es que sus emisores no se consustanciaron ni por vocación ni por interés con las bases de la informática y es por ello que constantemente -desde esta carencia en su psiquis- desdeñan naturalmente (es decir, no son conscientes de que lo hacen) los procesos de desarrollo, empezando por los puntos de apoyo específicos para tender el puente necesario desde el problema real hacia una “solución de software”

Por consecuencia, con estas condiciones bajo las cuales obviamente los resultados casi nunca son los esperados, es que se tiene (y se retroalimenta) una permanente visión devaluada de los informáticos.

Si a ello se le suman los innumerables y esperables problemas con los que lidian los programadores, es hasta obvio y escrito en la tapa del libro que su trabajo se verá fuertemente devaluado en relación a lo que debería ser en realidad, considerando la inversión hecha en el aprendizaje y las características del enorme esfuerzo intelectual que requiere desarrollar software.

La consecuencia “social” de esto es que cada vez se paga menos a un desarrollador porque las empresas saben que pueden conseguir más o menos fácilmente a desarrolladores jóvenes que no sólo son talentosos y entusiastas por tener todas las expectativas por delante sino que, sobre todo, son baratos.

La consecuencia material y económica “individual” de los informáticos es que se rinden a su realidad devaluada. Y de eso no es razonable esperar que haya un real interés de mejorar la situación.

A más largo plazo, la continuación de este esquema no augura buenas perspectivas y es un síntoma de que la vieja “Crisis del Software” sigue campante, sobrevolando como un ave de rapiña en espera del momento preciso para bajar a devorarse una y otra vez a sus infaltables presas.

Daniel
7 Guillermo 14 Ago, 2007 a las 3:55 am

Alguien sabe de algun caso concreto de indicios de una crisis de sw en la actualidad?
8 Gerardo Mejia 21 Ene, 2008 a las 5:04 pm

Claro, ha habido varias crisis del software, recuerdan Y2K? fue mas propaganda que el danio que causo, y una crisis secreta, porque tardo tando Win Vista en salir al mercado? ahi se los dejo de tarea…saludos
9 Santiago Lopez 28 Ene, 2008 a las 6:02 pm

Muy interesante el artículo, tengo una pregunta. Debido a los retrasos que surgen con la crisis del software, ¿cuanto es el tiempo que las empresas esperan para cancelar el proyecto?¿Cual es el tiempo “aceptable” de retraso?
10 Daniela Vargas 7 Feb, 2008 a las 12:56 am

Resolvieron mi duda,pero alguien podría decirme un poco mas sobre Y2K y cual crisis secreta. La verdad no se por que tardo Windows vista en salir. Pero en lo personal no me agrada no todos los documentos son compatibles y se pueden salvar. Los archivos de FAT no son faciles de pasar a NTFS
11 Daniela Vargas 7 Feb, 2008 a las 12:56 am

Resolvieron mi duda,pero alguien podría decirme un poco mas sobre Y2K y cual crisis secreta. La verdad no se por que tardo Windows vista en salir. Pero en lo personal no me agrada no todos los documentos son compatibles y se pueden salvar. Los archivos de FAT no son faciles de pasar a NTFS
12 EDICSON PARRA 22 Jul, 2008 a las 2:44 pm

pongan lo que necesitamos no babosadas
13 ARNOVI PAYANENE 22 Jul, 2008 a las 2:49 pm

ALGUIEN QUIERE SALIR CONMIGO?
14 ARNOVI PAYANENE 22 Jul, 2008 a las 2:49 pm

ALGUIEN QUIERE SALIR CONMIGO?
15 ARNOVI PAYANENE 22 Jul, 2008 a las 2:49 pm

ALGUIEN QUIERE SALIR CONMIGO?