Investigación: ¿Es el software inmortal?
febrero 21, 2012A lo largo de estos años en la universidad, hemos aprendido muchas cosas sobre el software. Nos han enseñado buenas metodologías, los requisitos, los ciclos de vida, los procesos, su evolución, patrones de diseño y arquitecturas, varias técnicas avanzadas de programación y en todas ellas siempre nos dedicamos a crear software, a mantenerlo, distribuirlo etc pero algo que hecho en falta en todas ellas es el ocaso del software. Hoy quiero exponer mi opinión y quiero que pensemos sobre el impacto que esto puede tener.
Antes de empezar, como en otras ocasiones, quería definir lo que entiendo por concepto de muerte en el software y el coma del software:
- Muerte software: Conocido por "Proceso de Retirada de Software", lo cierto es que la muerte del software la podemos identificar como el estado que describe el cese definitivo de todos los procesos o parte de ellos así como el código, documentación y datos que estos contengan.
- Coma software: Es el estado que describe la paralización temporal de todos los procesos o parte de ellos así como el código, documentación y datos que estos contengan.
Casi nadie nos paramos a pensar en las repercusiones que podría tener que nuestro software muriera de repente, y es que ni si quiera nos planteamos que alguien o algo pueda matar al software, el cual en la mayoría de los casos, pensamos que es inmortal. Esto es un vacío del conocimiento que muchos programadores llevamos encima y que solo pensamos en ello cuando nos sucede o cuando vemos al vecino que se ha hundido con todo el equipo y nos preguntamos el porqué. Yo pienso que el software que se concibe en un primer desarrollo y un mantenimiento posterior, no es inmortal y es que este tarde o temprano acaba sepultado por la competencia, por el desfase tecnológico, por la economía, la política o incluso los propios usuarios, sin embargo si creo que puede ser puesto en un estado parecido al coma humano, para más tarde renacer cuando sea necesario.
Pero vamos por partes:
1. ¿Muere el software o en cambio es inmortal?
El software se concibe con la idea de durar para siempre. Tanto es así, que no existe una parte en la asignatura de "Análisis e Ingeniería de Requisitos" de mi facultad, en la que veamos algo sobre requisitos del tipo "Cese del sistema". Es lógico pensar que tratemos al software como algo infinito, ya que a parte de querer venderlo no queremos dar una sensación de fragilidad.
Hay un ejemplo que veo interesante, que son las versiones Beta. ¿Cuando demonios se termina una Beta? A veces nadie lo sabe, otras en cambio intentan encuadrarlo en unos márgenes de tiempo, que raramente salen según lo esperado debido a la gran cantidad de variables que se deben manejar. Pienso que deberíamos matar a la versión beta o a las partes que no necesitemos, creando requisitos de adaptación que nos faciliten el proceso de automatización entre versiones finales y betas.
Y diréis, un software que puede ser inmortal es el de la banca. Hasta los bancos se arruinan y lo primero que pensamos que hacen es tirar del cable y desenchufar el sistema. ¿Y que pasa si hacen eso? ¿Qué ocurre con nuestros usuarios? ¿Todos sin dinero? Lo lógico sería crear un proceso de muerte o cese de las actividades de la aplicación cuando esta se concibió, que tampoco tiene que ser muy extenso, simplemente hay que saber que hacer, y no dejarlo en manos del destino, porque por regla general cuando se deja al software hacer lo que quiera, este no hace lo que queremos obviamente.
2. ¿Se puede programar el software para morir?
Si se puede programar para activar el proceso de muerte. Es sencillo, solo basta con crear un proceso en que establezcamos cuales son las pautas que necesitamos para que cesen todas las actividades asociadas al software una vez este o no necesite vivir más, o lo hayan matado a la mala sangre.
2.1 y si es así ¿Cómo podemos aprovecharnos de ello?
Podemos tener un control y una visión panorámica adicional de nuestro sistema que nos permitirá un control más exhaustivo de cada uno de los componentes software así como una distribución de recursos, tiempo y dinero más eficiente.
3. ¿Qué repercusiones tiene (económicas, tiempo, recursos) ?
Pensemos en una empresa E, que necesita crear una aplicación A que va a estar activa solo una cantidad T de tiempo. Este empresa crea la aplicación, realiza un gran esfuerzo en que esta funcione correctamente, con todos los procesos que requiere una creación típica y usando las metodologías que más se adapten. Cuando toque "cerrar el chiringuito" tenemos una cantidad de datos muy importantes que no hemos contemplado y que sino planificamos su corte en un principio y adecuadamente, nos puede suponer muchos recursos, tiempo y sobre todo un gasto de dinero innecesario.
Hablando con mi profesora de "Análisis e Ingeniería de Requisitos" Valeria de Castro, me comentó que se pueden generar requisitos por algo provisional (por ejemplo, por la creación de un módulo de servicio). Ella me puso el ejemplo de un puente provisional:
"Puede llegar a ser necesario la creación de un puente que conecte dos extremos, pero que a la larga sea innecesario. Este mismo pensamiento se puede trasladar al software y aunque no he visto previamente ningún caso de creación de Requisitos para el cese de partes de la aplicación, si que puede ser interesante crear alguno que ayude al proceso de retirada de ese módulo o aplicación sobrante."
4. ¿Cuál es el papel de los usuarios en el proceso de retirada?
Investigando, este puede ser el punto que más me ha sorprendido y es que los desarrolladores de software (en todos los niveles) no somos conscientes en ocasiones de la
importancia que tienen los usuarios en nuestra aplicación. En la mayoría de las ocasiones el éxito de la misma se ve reflejada por la respuesta de los usuarios y son ellos los que muchas veces acaban por destruir el software. Un ejemplo es el caso Google Wave. No se si habéis llegado a conocer esta aplicación pero se encargaba de crear conversaciones o publicaciones en tiempo real. Bien, google tuvo que dejar de invertir dinero en el porque no se usaba prácticamente y era más un estorbo que algo que pudiera dar beneficios. En este concepto quise indagar un poco más y se lo comenté a mi profesora de "Evolución y Adaptación del Software" Paloma Cáceres. Ella me explicó que el caso típico que se suele dar en el que muere el software son los prototipos, y es que cada vez que creamos uno, esto sigue un proceso que puede quedar en stand by, o lo que yo llamo Coma del software o incluso puede acabar en tragedia, es decir, muerte. Para ello pienso que sería necesario crear un simple Requisito o como comenté con anterioridad, algo que nos pudiera guiar para "dar boleto" al software, ahorrando tiempo y por ende, dinero.
Además, ella me comentó un ejemplo, que me dejó sorprendido:
"Hace muchos años, hubo un claro ejemplo de muerte de software por parte de los usuarios de la aplicación. Cuando Renfe actualizó sus sistemas de control de billetes en las estaciones, esta incorporó un sistema de "picado de billetes" por software. Este aplicación la controlaba el revisor, que se encargaba de picar el billete, dar una copia al pasajero y quedarse el con otra copia. Los usuarios, es decir, los "los revisores" se negaron a usar esta aplicación tal y como se había concebido para tal y fin, y esto supuso casi la muerte de la aplicación software que tanto dinero, tiempo y esfuerzo había costado crear y mantener."
Con esto podemos ver la importancia que tiene una buena gestión desde el minuto 0 del software.
5. ¿La moda influye?
Parece una tontería, pero el ser humano somos así en muchas ocasiones. A veces se crea una nueva tecnología, o simplemente una nueva tendencia social, por poner un par de ejemplos, y de repente nuestra aplicación software, que tanto cuesta mantener, cae en el olvido o peor aún, es derrotada por otra aplicación de la competencia. Las modas no se pueden controlar, pero si podemos controlar hasta que punto nos es rentable tener una aplicación "viva". ¿No creéis que estos "planes de emergencia de muerte software" se pueden planificar antes o incluso durante la vida del software?.
6. ¿Qué es la tecnología disruptiva y como afecta al software?
En ese hilo, quería comentar unas líneas sobre la tecnología disyuntiva, que es y como nos afecta:
- ¿Qué es?
Es una tecnología que llega años adelantada a su época y que divide el mercado poco a poco hasta fragmentarlo completamente.
-¿Cómo nos afecta?
Te quedas sin tu parcela software, hasta casos extremos en los que es necesario retirar el software, ¿pero que ocurre? que no lo planificamos, por lo que la sangría se convierte en un mar de código, datos y gente dando vueltas como patos sin cabeza por la oficina. Esto me recuerda a Blackberry cuando el iPhone salió al mercado. La historia es muy buena, antes de que saliera el iPhone, BlackBerry y Nokia se repartían el pescado y estos decían que no podían crear unas pantallas de más de dos pulgadas porque no aguantarían ni tres horas de batería. Y llegó el iPhone y destrozó todo lo que había a su alrededor. Directivos de BlackBerry tuvieron una reunión al siguiente día y hubo despidos, lógicamente.
7. ¿La política entierra el software?
A veces nuestros sistemas políticos entierran las bondades que puede aportar nuestro software. Podemos ver por ejemplo la aplicación web "Netflix" que no se atreven a venir a España por que aunque a la larga puede que les saliera rentable, lo cierto es que nuestra política de derechos de autor es tan restrictiva que nos les permitiría asentarse como han podido hacer en otros países. En este caso hablaríamos de un software nonato.
Pero peor puede ser que estés creando una aplicación y de repente venga el gobierno de turno y la cierre por vulnerar los derechos de autor, por ejemplo.
8. La gestión de la configuración y control de versiones VS Mortalidad Software
Por otra parte quería preguntar a un experto en Calidad y para ello me dirigí a mi profesor de "Calidad Software" Javier Garzás y le pregunté que para el, ¿qué es lo más importante para que un software se mantenga con vida?, el me comentó lo siguiente:
"La gestión de la configuración y el control de versiones en un desarrollo software son esenciales para que este no muera. La mantenibilidad suele ser una de las principales causas por las que el software muere a la larga. Hay que dedicar mucho tiempo a estas tareas, son requeridas y de ello depende la vida de la aplicación."
Esto es otro enfoque distinto y que comparto su opinión totalmente. Tuve la oportunidad de realizar tareas de Gestor de la configuración en uno de los proyectos en los que estuve asignado en mi etapa laboral y gran parte de los problemas internos se debía a una mala gestión del propio equipo. Se perdía mucho tiempo haciendo auditorías pero ganamos mucho más cuando lanzábamos las releases, ya que nos garantizaba un código mucho más depurado y optimizado y sobre todo consistente.
9. ¿Qué vive más, el software libre o el privado?
Por último, pensando y dando vueltas observé que el software libre a la larga acaba viviendo más que el software propietario. Y es que si Microsoft se hunde, adiós Office, pero si se hunde la distribución Ubuntu, ¿que ocurre con OpenOffice? Exacto, el software propietario depende de la plataforma, y la plataforma privada muere o bien por motu propio o bien por algunas de las razones expuestas en este post.
Esto es todo, espero que os haya gustado y si queréis algo, o tenéis otra opinión, no dudéis en comentar.
Por último dar gracias a mis profesores que me han ayudado a enfocar de distinta manera esta investigación.
0 comentarios
Sé respetuoso/a, en este blog caben todo tipo de opiniones con respeto y serenidad.