El cuento de Paco y la ingeniería del software

3
3248
Diagrama de caso de uso
Esto es uno de los diagramas que hacemos los informáticos, se llama diagrama de caso de uso. En este caso expresa (de forma simplificada) lo que puede hacer un Chef y un Crítico de comidas en una parte de una aplicación (programa) sobre un restaurante. El ejemplo está extraído de la wikipedia no se me ocurría un ejemplo sencillo, la verdad.

Nota inicial: debido a que la Ingeniería del Software es un tema muy aburrido, sobretodo cuando uno se inicia a él, he decidido contar de qué va el tema por medio de una especie de cuento, para entender sólo la idea básica (qué es, para qué se usa y por qué se usa). En mi caso me encanta la Ingeniería del Software, es más una buena parte del grado que estoy cursando va de ello. Hasta ahora sé lo suficiente de esta rama, como para haber aprobado una asignatura anual sobre ingeniería del software al final de mi antigua carrera.

Paco no era un chico normal. Para nada. Para empezar, él en vez de nacer con un pan bajo el brazo, nació con su propio driver para el manejo de la placenta. Cuentan que antes de aprender a hablar castellano, aprendió C puro. Incluso a los cuatro años ya había creado su propio compilador. Y cuando cumplió siete años, ya tenía lista su propia distribución de Linux.

Pero no todo fue oro. En la adolescencia fantaseo con cosas prohibidas como fueron un Windows XP pirata, aunque en una máquina virtual, y toda una pandilla de endemoniados programas privativos. En esa temporada su camello se llamaba Internet Explorer, él se dedicaba de distribuir sus virus en forma de esos programas. Se metía en foros y se reía de los usuarios que se tragaban las bromas pesadas que acababan con sus ordenadores en la casa de aquel vecino informático, siempre disponible para echar un cable cuando un ordenador se rompía en el vecindario. De forma paradójica, el adolescente Paco también era uno de esos vecinos informáticos que arreglaban ordenadores gratis.

Para Paco las asignaturas de letras siempre fueron para fracasados (pero él bien que las aprobaba raspando), y una vez que terminó su bachillerato se enfrascó en una, para él apasionante, carrera de cinco años llamada Ingeniería Informática Superior, lo cual, desde su simplista punto de vista, le dio total legitimidad para sentirse superior ante los alumnos de magisterio.

Allí, entre asignaturas a las que fusilaba con matriculas de honor con sólo su mirada, conoció a su gran, verdadero y único amor. Al principio, lo típico, que si los primeros tonteos, que si te toco una variable por aquí, que si te rodeo con un bucle. Y luego ya fueron a saco, que si te meto una multitarea pero antes pongo una protección synchronized. Ella tenía un nombre, ella se llamaba Java.

Y mira que sus compañeros de universidad, que le respetaban y le veneraban (siempre que acudiera él para ayudarles en los ejercicios o en algún que otro examen), le dijeron a Paco que su obsesión por Java no era normal. Pero él ni caso, oye, en su mundo Java no era un lenguaje de programación, sino lo más parecido a su media naranja.

Pero con lo que Paco no contó es que cualquier carrera de informática es una carrera que, básicamente, comienza por el final y acaba por el principio (un paréntesis: no quiero decir con esto que todas las asignaturas de último curso deban de ser de primero). Si al principio la asignatura más importante era la que trataba más sobre informática, al final es la que trata más sobre economía y empresariales aplicada a la informática. Organización del trabajo, diagramas, Metrica 3, documentación,… Todo un cumulo de letras que a Paco le dejó KO mientras la malvada asignatura reía y reía sobre él. El gran enemigo de Paco se llamaba Ingeniería del Software, y le persiguió durante toda su vida.

Porque cuando Paco creyó que ya había acabado con Ingeniería del Software, con un notable (la nota más baja de su carrera), resultó que su enemigo nunca moría. Eran como el bien contra el mal, la vida y la muerte, el escepticismo científico y la pseudociencia, Sonic y Dr. Robotnik,… Ingeniería del Software siempre estaba allí, desde el proyecto fin de carrera de Paco, hasta todo trabajo que pisó. Él decía que sólo quería ser un programador por tal de no saber nada de Ingeniería del Software. Sin embargo, el resto de compañeros suyos sí optaron por subir de categoría, estando cada vez más y más en contacto con la Ingeniería del Software, hasta llegar a Jefe de Proyecto, que era para Paco como declararse un esbirro de la Ingeniería del Software.

Hasta que un día le tocó a él. La vida adulta le obligó a comportarse bien, a enderezarse, y tomar la senda de la Ingeniería del Software. A Paco ya le tocaba vivir con su novia de carne y hueso y dejar de una vez de ser un parásito de sus padres. Y cuando llegó ese día, la Ingeniería del Software y él se sentaron en una misma habitación para firmar las paces. En el contrato ponía un nombre temible para Paco, y era ‘Analista’.

Así que la Ingeniería del Software se sentó delante suya, con traje, corbata y zapatos. Los dos bandos extremos alcanzarían un pacto final. Y se reprodujo el siguiente dialogo entre ellos:

– Te estoy dando una bonita oportunidad, Paco. De una vez debes de reconocer la verdad.

– ¿Qué verdad?

– No lo notas, ¿verdad? – y le miró a los ojos – ¿Aún no eres consciente del gran daño que has hecho? A tus propios compañeros de universidad, a tus compañeros de trabajo, a tus superiores,… Todos ellos lo saben, Paco. Saben que nunca cumpliste las reglas. Saben lo que haces para seguir en tu puesto, pero ellos, idiotas, piensan que se debe todo a que no les comprendes. Les da vergüenza decirte la verdad.

– No sé a qué te refieres. Yo programo perfectamente. Mi código está tabulado correctamente, no tengo errores de programación, y siempre las cosas funcionan a la primera. Además si estoy aquí, apunto de tener un aumento de puesto y sueldo, será por algo.

– Claro que sí, rata del conocimiento. Dime Paco, ¿cuándo fue la última vez que dejaste un comentario en el código? ¿Sabes que ayer otro becario más rogó a los pies de los de recursos humanos que ‘por favor, sáquenme de este proyecto, no puedo más’, tras intentar entender una sola línea de un programa hecho por ti? El pobre, él sólo quería comenzar su carrera laboral tras terminar la universidad. Pero claro, resulta que, tras tantos años que has estado como programador, más del 80% del código de esta empresa ha sido creado por ti, lo que está causando un gasto enorme en personal cualificado. Además de un código complicado y difícil de entender, ni un misero comentario explicando qué haces. Han habido tantos que no han soportado las pruebas, Paco. Tantos.

– Eso es mentira.

– Ah, sí. Con que ésas tenemos. Ahora verás. – Y la Ingeniería del Software le pasó a Paco una hoja con un subprograma – Venga, valiente, adivina qué hace eso.

– Pues ya lo pone aquí, en el título “eliminaUsuarioConContraseña50EnEstadoErroneo9586”.

– ¿Y eso significa el qué?

– Pues, déjame que mire un poco el código. Y…

Pasó media hora hasta que Paco se dio por rendido.

– ¿Pero quién demonios hizo este código?

– Tú fuiste Paco. Tú, nada más llevar dos meses trabajando en esta empresa. Y éste es sólo un ejemplo del gran mal que has dejado aquí. Al contrario que tus compañeros, nunca quisiste usar ni siquiera el más mínimo de mis fundamentos: comentar el código y dejar las cosas claras para que otro programador cualquiera las comprenda con tan sólo echar una ojeada. Cosas como ésta le costó jugarse a más de uno de tus antiguos jefes el puesto, debido a que no se verificaban las principales normas de calidad del software, y tenían que mentir en la fichas de calidad (pero tuvieron suerte porque nadie intentó contrastar datos). Sí, eres un gran programador y eres capaz de resolver problemas muy difíciles, y por eso eres útil para esta empresa, y por esto es por lo que te quieren ascender. Pero antes de subir debes pensar que nunca hiciste caso.

>> Pienso que ahora te aplicarás como todos, estoy seguro. Cuando tengas que organizar un proyecto con diagramas, cuando tengas que echar un cable para que tus superiores planifiquen los proyectos y estimen horas (teniendo siempre en cuenta que el rendimiento de cada persona es diferente), cuando tengas que pensar en que el cliente quiere un producto de calidad, ajustado a lo que él quiere, e intentando siempre inferir lo que él intenta decir qué quiere, pero no te lo dirá explícitamente (pues poca gente sabe lo que realmente quiere cuando va a comprar algo). E incluso más de una ocasión teniendo que rechazar a tu querida Java como opción para un proyecto, porque no se adapte a lo que quiere el cliente.

>> Y también tendrás problemas. Puede que tengas que hacer el esfuerzo de escribir documentación de análisis mientras los programadores hacen sus tareas, puede que el cliente le diga a tu equipo, de forma clara, que el producto no tiene nada de lo que dijo, y tengas que volver a dibujar diagramas. Tendrás que sacar requisitos casi de la nada en más de una ocasión. Discutirás con otros analistas e incluso con jefes de proyecto. Sin contar la documentación de cada cosa que hacéis, pues todo debe quedar perfectamente detallado, desde la funcionalidad hasta las pruebas.

>> Y te alejarás de la programación progresivamente, hasta llegar a Jefe de Proyecto, puesto en el cual tendrás que ocuparte más de la planificación del proyecto, la documentación de calidad, las largas reuniones, el contacto directo con el cliente, y de viajes. Porque esto es realmente lo que aceptaste ser al elegir una ingeniería informática.

Paco firmó el contrato, aceptando su nueva vida.

Es curioso pero cuando todo el mundo piensa en un ingeniero informático trabajando para una empresa, mucha gente se imagina un tipo como el antiguo Paco, un friki obsesivo de la programación y del mundo de la informática. Incluso me he tomado la licencia de exagerar más el personaje ficticio. Cuando, en la realidad, existen montones de trabajos diferentes, y más de uno de ellos no tiene que ver con programar o montar ordenadores (rompiendo mitos: en donde trabajo si un ordenador se rompe, para arreglarlo jamás lo tocamos nosotros, los programadores, lo tocan los de sistemas). Cuando terminas una ingeniería informática o un módulo es verdad que si eres un gran programador puedes resistir años en este negocio, pero tarde o temprano (tanto si eres de modulo, como un ingeniero, como si vienes de un curso de programación), algún día, puede que subas a los cargos más cercanos a la Ingeniería del Software, y más lejanos a la programación, más lejanos a lo que la gente suele considerar como informática.

Lo que he intentado con este texto es explicar la idea básica de la Ingeniería del Software. La Ingeniería del Software es, en definitiva, planificar cómo se va a programar una enorme aplicación, es poner reglas de codificación que los programadores deben de cumplir y que a mucha gente no les gusta usar al principio (ésas que Paco no cumplió), es hablar con clientes que, seguramente, sólo puedan hablar contigo en inglés y es más que seguro que tengas que intuir qué es lo que realmente quieren, y es saber en qué estado se debe de quedar el proyecto para su etapa de mantenimiento, que es la etapa final. Algo así como no dejar para mañana lo que puedas hacer hoy (aunque en alguna que otra empresa esto no se cumpla porque haya que planificar al mismo tiempo que se programa y hacerlo todo con prisas y horas extras etc etc). Es duro, al principio, y puede que con una excesiva visión empresarial que haga echarse atrás a más de un friki informático, pero, oye, es lo que ayuda a que los programas más enormes se terminen haciendo.

3 Comentarios

Dejar respuesta

Please enter your comment!
Please enter your name here

Límite de tiempo se agote. Por favor, recargar el CAPTCHA por favor.