El nacimiento de la Ingeniería del Software

En el vídeo anterior tratamos sobre qué es la crisis del software y qué consecuencias a nivel humano tuvo. En este vídeo continuaremos tratando el tema hablando sobre las metodologías que surgieron para paliar este problema, del fenómeno bala de plata y de si este es un problema del pasado con algunas historias trágicas en su haber o si, por el contrario, es correcto hablar de ello como algo que aún no ha acabado. Os damos la bienvenida a Programando Otra Historia. Antes de continuar, un inciso. ¿Te gustaría apoyar a nuestro canal? No te olvides de darle a me gusta y, si no lo estás, suscribirte para no perderte futuro contenido. Ahora sí, continúa.

Como paso inicial dentro del Comité de Ciencias para el Estudio de la Crisis del Software de la OTAN en 1968 y 1969, se concretaron una serie de cambios y acciones a implantar para la elaboración de software de calidad. En el documento se mencionan las tareas a llevar a cabo con nombres que sonarán a cualquier desarrollador que haya cursado no hace mucho alguna carrera universitaria. El establecimiento de estas fases y su definición precisa ayudaron a iniciar lo que conocemos como ingeniería del software.

Las fases de desarrollo intentaban identificar dónde había que realizar según qué tareas Y más importante, intentaban aislar tareas como la planificación y la investigación en áreas diferenciadas del desarrollo, instalación y mantenimiento.

Así se intentó dar un rigor más cercano al resto de ingenierías e intentar ser más certeros a la hora de aportar fechas y duraciones más precisas. Aun así, el desarrollo de software se basa en la implementación de software sobre sistemas que normalmente tienden a ser muy novedosos. Implementan nuevas formas de hacer algo o incluso se desarrollan sobre dispositivos nunca vistos antes.

Por ejemplo, alguien que desarrolló un programa de calendario en 1980 sobre un sistema basado en texto y en un lenguaje concreto podría darnos una estimación de cuánto tardaría en hacer lo mismo para ver un calendario en unas gafas de realidad aumentada y que puedan anotar una cita leyendo una tarjeta que tenemos en nuestra Muchos profesionales se dieron perfecta cuenta de que cuando un equipo de desarrollo recibía un encargo para desarrollar una solución, se encerraban, planificaban, desarrollaban y daban poca información al cliente.

Quizás un desarrollo de una semana terminaba con una aproximación certera de qué quería el cliente, pero no pasaba así cuando el desarrollo se extendía durante meses o años y al finalizar no cumplía las expectativas del cliente.

Barry Boehm estimó el costo de software en Estados Unidos de 1981 en 40 billones de dólares, 2% de su producto interior bruto. En 1985 en 140 billones de dólares y en 1998 se estimó entre 300 y 400 billones de dólares.

Es mucho dinero, sobre todo teniendo en cuenta cuánto de este dinero termina derrochado. En un reciente estudio del consorcio de Stripe reportaron que hay unos 18 millones de desarrolladores de software en el mundo y trabajan de promedio 41 horas por semana, de las cuales destinan alrededor de 17 horas en paliar la deuda técnica, es decir, software de baja calidad o que no cumple correctamente las expectativas y debe arreglarse en un futuro más cercano que lejano. Hablamos por tanto de que tan solo el 42% del tiempo de un desarrollador es empleado para generar código de calidad. En el mismo informe se detalla que tan solo el 22% de proyectos terminan en plazo, dentro del presupuesto y con la funcionalidad solicitada, mientras que el 60% terminan con retrasos, implicando un mayor presupuesto o con funcionalidad parcial, y el 18% terminan en abandono.

Como habrás adivinado por los datos dados hasta el momento, la creación de la ingeniería informática no fue suficiente porque incluso en industrias tan sensibles como las salud o los medios de transporte de masas, aún se siguen sucediendo fallos que causan muertes.

Un término que entró en auge en el sector fue el de las soluciones bala de plata. Muchos profesionales desde los años 70 a los 90 aseguraban haber descubierto su bala de plata, su proceso o metodología para ayudarles a resolver todos los problemas del sector.

Fred Brooks escribió un artículo en 1986 asegurando que no hay bala de plata, indicando que no hay forma de subir ni tan siquiera un 10% la productividad en los siguientes 10 años con ningún método. Sin embargo, a principios del siglo XXI comenzó a surgir una nueva ola de pensamiento que daría de nuevo de qué hablar.

Los cambios no suelen suceder de la noche a la mañana. Desde que en 1968 el Comité de Ciencias estableciera unos procesos definidos que terminarían llamándose metodología en cascada, por hacer mención a una serie de pasos secuenciales para desarrollar un software, Muchos otros comenzaron a especificar sus metodologías propias y matizar o cambiar la forma de desarrollo.

Podemos trazar una línea, aunque no sería recta, por la que discurrirían metodologías como: prototipado, donde se establece el desarrollo rápido de un código como fase de investigación y, tras analizar qué puede hacerse y conseguirse, se emplea a modo de mapa exploratorio para trazar la verdadera ruta a seguir.

Iterativo: donde se desarrolla la mínima expresión de qué se quiere conseguir y a partir de ahí se va iterando y evolucionando en algo más y más grande.

Espiral: Boehm en 1986 combinó la metodología en cascada con el iterativo para generar una serie de fases en pequeñas iteraciones y así ir consiguiendo algo más grande cada vez, pero siempre desarrollado por las fases definidas en la cascada.

O desarrollo rápido de aplicaciones, por James Martin en 1991, combina esta vez la mecánica de prototipado con las iteraciones produciendo un prototipo mínimo pero con capacidad para ser iterado.

Proceso unificado racional: una serie de iteraciones llevadas desde la especificación conceptual de qué se quiere desarrollar a través de diagramas que presentan la información del mundo real modelada para ser implementada fácilmente en un sistema informático. Este, en emplea los diagramas UML, lenguaje unificado de modelado.

Las metodologías ágiles. A estas metodologías le seguirán otras de más alto nivel, no solo integrando qué hacer para desarrollar, sino también integrando los rituales y formas de cooperar dentro del equipo para desarrollar el software, generando metodologías como Extreme Programming de Kent Beck Ron Jeffries y Walt Cunningham en 1999 y que en base a la ampliación con respecto a la programación iterativa, agregando pasos hacia atrás con la refactorización para asegurar una reducción de deuda técnica, una revisión en equipo del código ya sea por revisiones o programación por parejas y una entrega rápida con muchas pruebas y comprobaciones para lograr una integración continua del software.

Scrum. Mike Beadle, Jeff Sutherland y Ken Schwaber en 1995 publicaron la culminación de la idea de Scrum en el desarrollo de software tomada inicialmente de una idea anterior en otras industrias. Al igual que Extreme Programming, Scrum se basa en la definición de unos rituales llevados a cabo por el equipo, una dinámica de trabajo y comunicación con el cliente que incrementa las posibilidades de éxito.

DSDM, Método de Desarrollo de Sistemas Dinámicos, fue creado en 1994 por Arif Van Beneekum. Fue integrante de este consorcio como previo usuario de RAD, al igual que muchos otros. DSDM propone una serie de prácticas como los talleres de facilitación, el modelado y desarrollo iterativo, la priorización de tareas llamada coloquialmente MOSCU, por sus siglas para lo que debe hacerse, lo que podría hacerse, lo que puede hacerse y lo que no se hará. Fue popular en Reino Unido sobre todo.

Alistair Cockburn, en los 90, promovió una serie de metodologías ligeras que ordenaban los grupos de trabajo por colores basándose en minerales, teniendo así Crystal Clear para equipos de hasta 8 personas, Yellow para equipos de entre 10 y 20, Orange de entre 20 y 50, Red de 50 a 100, y le seguirían con este ritmo de crecimiento Maroon, Blue y por último Violet. Y otras muchas metodologías que han ido surgiendo en este siglo. Si te dedicas al desarrollo de software, te sonarán los métodos importados desde Japón, como la metodología Lean o la metodología Kanban, también conocida como método Toyota. En ocasiones, estos grupos han mezclado estas metodologías obteniendo otras, como el caso del método ScrumBan, como mezcla de Scrum y Kanban.

Los creadores de muchas de estas metodologías y otros programadores preocupados por el desarrollo de software se reunieron a principios de 2001 en una reunión donde se acordó y firmó el Manifiesto Ágil. Este manifiesto establece principalmente 4 puntos haciendo énfasis a las proposiciones enumeradas al principio de las frases y reflexionando sobre cada uno de estos conceptos. Los conceptos son: individuos e interacciones sobre procesos y herramientas, software funcionando sobre documentación excesiva, colaboración con el cliente sobre negociación contractual y respuesta ante el cambio sobre seguir el plan. Sin embargo, aun poniendo a disposición una cantidad tan elevada de metodologías ágiles y siendo el manifiesto así de simple, muchas empresas y principalmente sus empleados y clientes sufren la carencia de esa flexibilidad y el incumplimiento de estas promesas. Y el foco vuelve pronto al proceso, a la documentación excesiva, a la negociación contractual y a seguir el plan incrementándose la cantidad de personas, los presupuestos o dinero a gastar y el tiempo mientras decrementan los éxitos.

Lo que sí quedó claro a raíz del artículo de Brooks es que no hay una metodología única. No existe una bala de plata y, en cierta forma, esto es positivo porque indica que el sector es lo suficientemente maduro para buscar una metodología y una dinámica que encaje en su forma de trabajar.

La crisis del software es un término complejo y que define una situación de insatisfacción por parte de proveedores y consumidores de software. No existe un método para resolver la situación Sin embargo, aún hablamos de esta crisis, quizás porque aún escuchamos casos donde la falta de calidad del software nos deja titulares sobre accidentes o vulnerabilidades que dejaron al descubierto datos sensibles o sistemas que dejaron de funcionar debido a un problema no anticipado. Entonces te toca a ti. ¿Y tú qué opinas? ¿La crisis del software en realidad está resuelta y lo de los titulares son solo casos aislados que escuchamos? ¿O aún queda algo más que debe hacerse en el sector para cambiar esta situación? Te leemos en comentarios.