Home » Opinión » Correcciones y mejoras, estado de beta continua
Banner Beta

Correcciones y mejoras, estado de beta continua

La ingeniería del software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software (“IEEE Standard Glossary of Software Engineering Terminology,” IEEE std 610.12-1990, 1990)

Según la ingeniería del software, existen una serie de fases de desarrollo del mismo: alfa, beta, RC y RTM. De una manera clara y concisa, un estado alfa es el de un producto no terminado en su totalidad (solo partes del mismo) pero que ya muestra las suficientes funciones como para realizar pruebas modulares (por partes separadas de este) pero no integrales (pruebas en su conjunto). Una beta es un producto terminado, una versión final que cuenta con toda su estructura y funcionalidad, pero que puede mostrar fallos en su funcionamiento o realizar alguna tarea de forma diferente a como se especificó. Por lo tanto requerirá de correcciones. RC es la versión candidata a lanzamiento: un producto ya terminado, probado y verificado. Un producto que, salvo errores que puedan presentarse graves, será aquel que se lance finalmente a la disponibilidad general. RTM es la versión en disponibilidad general (release to manufacturing o versión para manufacturación).

La teoría es bella. Si nos vamos a los inicios de los tiempos del software, esta teoría es perfecta y se aplica tal cual. En su día, con ordenadores donde el producto se manufacturaba al público en soportes físicos (cintas de cassette, disquettes, CD-ROM…) y donde no existía una conexión a internet de manera global, esto se cumplía a rajatabla. Pero hoy día ya no sucede esto ya que el modelo de distribución del software ha cambiado radicalmente.

De un software paquetizado a uno vivo

En la época pre-internet tenías MSDOS 6 y cuando salía el 6.2 traía nuevas funciones. El WordPerfect 5.0 era genial y el 5.1 incorporaba funciones aun mejores. El Windows 3.1 era un entorno de trabajo gráfico en ventanas monopuesto y el 3.11 era para trabajo en grupo. El concepto de la corrección de errores entre versiones era muy difuso porque había determinados productos a los que se les presuponía (en algunos casos era así) que no tenían fallos. La ingeniería del software bien aplicada, no admite errores en fase RTM.

Pero veamos cómo han cambiado las cosas: el “Day of the Tentacle”, juego lanzado en el año 1993, ocupaba 5 discos HD de 1.44Mb en su versión PC VGA de 256 colores a 320×200 de resolución, con la introducción hablada en inglés y música en formato MIDI. El juego era el que comprabas en la tienda y punto. No presentaba fallo alguno y no necesitó jamás de una actualización, un parche o nada parecido. Instalabas y jugabas. No había más. La versión Remastered que ha salido hace poco ya lleva 6 versiones publicadas con diferentes errores corregidos en cada una de ellas. ¿Qué sucede?

Day of the Tentacle

En muchos casos nos hemos acostumbrado a que los productos no estén terminados, al “tú lanza que ya si eso lo vamos arreglando poco a poco”. Y con casos flagrantes de apps o juegos con nuevas versiones que suponen GB de descargas cada poco tiempo. Incluso existe un nuevo modelo de mercado para juegos donde el cliente paga por un producto no terminado, aun en fase beta (incluso alfa) y es el propio jugador quien participa del proceso de creación de este.

Pero no vamos a referirnos a estos casos o a una mala ingeniería o calidad de producto, si no a aquellos desarrolladores que sí hacen bien su trabajo pero que han visto que el mercado ha pasado de cerrar un paquete lleno de galletas y venderlo a otro concepto donde el paquete tiene que ir adaptándose al gusto de los clientes y unas galletas que variarían en forma o número. O tal vez saquen del paquete alguna galleta de otro tipo que se coló en la cadena de producción y nadie se percató.

El software ha sufrido un cambio de concepto importante al generalizarse a la mayoría de usuarios y abrir sus canales de distribución a casi cualquier persona: ahora ya no existe el software que tiene un inicio, un desarrollo, pruebas y cierre. Ahora hay muchos motivos por los que casi cualquier software es vivo y como tal, las versiones del mismo son puntos lo suficientemente estables dentro de su desarrollo, que se deciden sean RTM. Son betas continuas que se cierran en un momento determinado para darle salida mientras se sigue trabajando en el producto.

Y todo se debe a un concepto claro: el mantenimiento evolutivo. ¿Realmente un software podría darse por terminado, como un edificio o un coche, y como tal venderlo y punto? Porque a día de hoy hasta los coches reciben actualizaciones de software que les permiten nuevas funciones. A día de hoy un software está en un permanente estado evolutivo que lo obliga (si queremos que el producto sobreviva en el voraz mercado actual) a incorporar nuevas funciones, pulir determinados aspectos a través del feedback de los usuarios, corregir errores o mejorarlo. O también, como ya hablamos en otro artículo, a adaptar o corregir el mismo para que funcione en nuevas versiones de los sistemas donde se ejecuta.

Porque también tenemos que pensar que las fases beta, antes, estaban limitadas al equipo de trabajo del software o (tal vez) una empresa externa. Y hoy día, los beta testers somos todos y el software (para no perder capacidad de retención de usuario) se adapta en tiempo real a nuestras necesidades y soluciona problemas que un equipo que llega a estar viciado de probar una y otra vez lo mismo, no es capaz de detectar.

Marketing

Otro factor es la incorporación del marketing al proceso productivo. Dicen que el marketing es aquello que te hace comprar lo que no necesitas con el dinero que no tienes. Pero sin duda, este va a hacerte creer que realmente lo necesitas: el marketing genera necesidades. Y como tal, la forma más perfecta de este es sin duda el que permite que un producto se adapte a las necesidades reales de un cliente y para eso (en software) existen las analíticas que nos permiten ver qué hacen nuestros usuarios en un conjunto de datos anónimos que nos cuentan cuál es la función más usada de nuestro software, la que menos, cuánto tiempo pasan de media, con cuántas archivos, casos o circunstancias se ha trabajado, hasta dónde se ha llegado (por ejemplo, en un juego)… Las apps potencian aquellas funciones que más usan los usuarios y en un juego por niveles las analíticas detectan que un número muy elevado de sus usuarios se frustran y abandonan el juego en el nivel 54 por lo que suavizamos la dificultad para mejorar la retención y evitar ese problema.

A día de hoy, el estudio de determinados tipos de software es casi tan esencial como el desarrollo del mismo porque la única forma que tenemos de saber cómo responde un usuario a nuestro software es dándoselo y ver qué hace. No hay otra forma más eficiente.

Marketing

Esto es marketing de apps. No es coger un juego o una app, anunciarlo y conseguir descargas. Eso es solo una parte: la otra es leer e interpretar los datos de uso, instalaciones, retención, poblaciones… Si hacemos una campaña de captación de usuarios, tendremos que tener claro cuál es nuestro público objetivo. Y además, cómo conseguir que el usuario que descargue la app no la desinstale al momento. Todo esto, yo lo sigo llamando marketing pues lo que hace es modificar el canal de venta para su cliente, adaptándolo.

Imaginemos una app o un juego que presentan, nada más arrancar, un tutorial que nos explica cómo funciona. Ese tutorial es un peligro potencial pues si es largo, puede hacer que el usuario se canse de tanto leer instrucciones y automáticamente reciba la señal que no queremos: “esta app es muy compleja”. ¿Cómo lo arreglamos? Incluyendo el tutorial dentro de la experiencia de la app. Si estamos en una app de tareas, presentemos el tutorial mientras la persona crea su primera tarea a voluntad: pasamos de darle unas instrucciones inertes a ser un amigo que lo guía sobre cómo ha de usar la app la primera vez. Un amigo al que le puedes decir en algún momento: “ah, vale, ya sé cómo es” y cerrar el tutorial. Eso es marketing de el software: adaptar las experiencias de uso, no solo dedicarte a vender una imagen. Eso es lo que hacen aquellas apps o juegos que tienen unos ingresos sostenibles en el tiempo.

Seguridad

Antes te instalabas un software y, aunque los había, rara vez se podían encontrar fallos de seguridad. Tal vez alguno recuerde aquel procesador de texto que cuando incorporaba la contraseña para los documentos, si visualizabas el contenido en bruto, podíamos ver la clave que tenía en texto plano. O tal vez ese Windows que si se nos olvidaba la clave, borrábamos y mágicamente esta era todo espacios. Pero hoy el software tiene una responsabilidad mucho mayor y se ejecuta en diversos estamentos, no solo un disco duro local.

Tenemos software que se ejecuta contra un servidor (como el que permite que esta página web funcione), software instalado en dispositivos como móviles, tabletas o incluso coches o televisores. Y hoy, todo quiere estar conectado a internet y todo tiene una forma de acceder que nos pretende garantizar que solo nosotros seremos quienes accedan. Pero el software, todo, tiene un mal endémico sin solución real: los fallos de seguridad.

Zero-day

Y no hablamos de virus o troyanos (que es lo que se engloba como software malicioso), si no de ese fallo en un software que el fabricante no descubrió en sus pruebas y que supone un verdadero peligro. Esto va más allá de un fallo no detectado que cierre un software en caso concreto (que también es un fallo a corregir). Nos referimos tal vez a un navegador que al visualizar un PDF con una tipografía incrustada, haga un proceso de instalación en su sistema de dicha tipografía que permita que si lo que hay en la tipografía no es tal si no un trozo de código, le permita ejecutar algo que pase la seguridad del sistema y le permita tomar el control del mismo. Puede que una hoja de cálculo que permite fórmulas, las procese de una forma que permita ejecutar instrucciones en un sistema remoto sin permiso. Peligros reales que permitirían a cualquier “malo” hacerse con el control de nuestros datos o sistema sin nuestro conocimiento. Y no, eso no lo detecta un antivirus. Y esos fallos, ante los que no estamos protegidos nadie en ningún sistema, solo pueden ser corregidos mediante actualizaciones de nuestro software.

Un software cada día más complejo, con más funciones, con millones (literalmente) de líneas de código y que cada día usamos con la garantía que alguien detrás vela por nosotros.

Ciclo de vida continuo

Existe un método de desarrollo de software denominado integración continua. Este, básicamente, permite generar versiones de prueba cada poco tiempo en base a cada pequeña incorporación. Es un divide y vencerás donde el conjunto completo del software incorpora las funciones según se desarrollan y se prueban y verifican en el conjunto: primero para ver si esa incorporación no impide que el programa completo compile (muy importante) y luego para lanzar los suficientes test de pruebas (tanto automáticos como de usuario) que nos permitan validar que el módulo o función se ha incorporado correctamente (tal vez, un cambio) y que nada ha sido afectado.

Youtube

El ejemplo más claro de esto son las apps de Facebook o Youtube, que ya no informan de mejoras algunas. Simplemente, cada dos semanas paquetizan una nueva versión y la suben a las correspondientes tiendas. ¿Por qué? Porque si tuvieran que poner fechas a un cierre de la misma, no sacarían nunca versiones nuevas por la gran cantidad de cosas que tienen que hacer dentro de la línea de tiempo de desarrollo. Aunque no veamos mejoras por fuera, no quiere decir que no las haya por dentro. Todas estas apps funcionan con un proceso de integración continua, como Apple con Swift, que publica una nueva versión también cada 2 semanas. Todas son completas pero ninguna puede ser considerada final porque ese concepto dejó de existir.

De esta forma, el software no tiene una fecha de cierre en el que digamos: venga, se acabó, bravo. No es así. El software puede vivir tanto como queramos. Tal vez pensemos que el Office 2011 era un producto final, pero no lo era porque vive en Office 2016 y tuvo unos cuantos Service Pack de por medio. La ingeniería del software, cuando habla de versionado, define que una major version (donde cambiamos de la 1.x a la 2.x) se lanza porque ha sufrido una re-escritura de su código en un alto porcentaje (sufre grandes cambios y mejoras).

Hoy día, esto no sucede y ese concepto ha quedado obsoleto. Hoy día un Firefox a cada revisión genera una major version, por citar solo un pequeño ejemplo. Y aunque OS X lo hace correctamente y sigue siendo 10.11 (lo que indica que el código en sí ha evolucionado desde la 10.0 pero no ha sufrido una re-escritura completa de su mayor parte en un momento concreto) en iOS, la versión 9 no es una re-escritura de la 8 como mandarían los cánones del versionado: sigue siendo una revisión. OS X trabaja con minor versions pero iOS no.

Y esto es debido, obviamente, a que nunca podemos dar por realmente terminado un software si no que este permanece vivo en un continuo proceso de evolución y cambio: ya sean los necesarios procesos de marketing que adaptan el producto a las necesidades de los usuarios, la necesidad de retener a este y que no cambie a otra opción, la seguridad, los errores no detectados por el equipo de pruebas pero sí por millones de usuarios activos… son muchos factores que han cambiado el paradigma de la ingeniería del software hacia otro modelo diferente. Un modelo donde vivimos en un estado continuo de beta y donde nuestra responsabilidad como desarrolladores es que el producto esté lo mejor posible y más pulido en cada nueva versión, pero nunca dejar de trabajar en el mismo.

El mercado es duro, pero no imposible. Dejemos de pensar que una vez fabricada la caja vendemos las patatas fritas de dentro… porque el software ya no es así. Good Apple Coding.

Acerca de Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Otras recomendaciones

El problema de la formación tecnológica

El problema de la formación tecnológica

Aprender mientras trabajamos en un proyecto. Uno de los mayores errores que se cometen hoy día en el mundo tecnológico. Al final, los responsables de proyectos hacen lo que pueden con lo poco que tienen y muchas veces las cosas funcionan "casi por casualidad". Una buena formación es esencial, tanto contratada como dar al empleado el tiempo necesario para conseguir la formación por sí mismo. Analizamos este problema presente en el mundo laboral tecnológico hoy día.

  • Eduardo González Joyanes

    Julio, como te lo curras 😉
    Buen artículo