Ingeniería del software

El término ingeniería del software resulta muy controvertido debido a la existencia de muchos detractores que ven más adecuados otros términos como por ejemplo el término desarrollo de software.

De hecho pese a que creo en el concepto uso con más frecuencia el de desarrollo de software.

La ingeniería del software es una disciplina que tiene como objetivo que el software que se desarrolla y sus productos complementarios, como por ejemplo, la documentación, sean de calidad (en todos los sentidos, no solo que verifique los requisitos funcionales) a través de un proceso que sea productivo para el que lo implementa.

Hay muchas definiciones académicas o de autores conocidos de este término. Me gusta mucho la de Bauer (1972) “Ingeniería del software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales”.

Detrás de la ingeniería del software tiene que haber necesariamente métodos (metodologías y procesos) que lleven desde la idea inicial de un programa a un producto instalable, que funcione y sea mantenible. Precisamente la no aplicación de esas metodologías como parte del proceso de desarrollo y el no establecimiento de unos controles de qué es lo que se está haciendo es la que ha llevado a que el término ingeniería del software haya quedado relegado y se utilicen, como comenté al principio, términos más generalistas como desarrollo de software.

Como he dicho anteriormente creo en la ingeniería del software entre otras cosas porque precisamente la no aplicación de principios metodológicos es lo que ha dado lugar a la crisis del software o lo que es lo mismo, productos de baja calidad, costosos y fuera de plazo. Estas características están presentes en gran parte de los sistemas con los que trabajamos, se puede mirar para otro lado, pero la realidad es esta por lo que la crisis del software no es un concepto del pasado sino algo muy presente y desgraciadamente y, si no cambian las cosas, con bastante futuro.

Generalmente se asocia metodología a burocracia y no tiene por qué ser así. No se trata de coger Métrica v.3 (o cualquier otra) y seguirla a rajatabla sino que se trata de establecer unos procesos en el desarrollo de software que sean repetibles en proyectos que tengan una serie de características comunes (lo que abre la posibilidad a la existencia de diferentes tipos de metodologías en función de la naturaleza de lo que se vaya a desarrollar) y en los cuales exista una realimentación de los resultados obtenidos con el mismo de manera que se puedan ir perfeccionando.

La metodología por sí misma no garantiza nada, salvo que en proyectos similares se actúe de la misma forma (que no es poco), pero establece un marco que ejecutándose de manera adecuada en todas sus fases abre el camino al desarrollo de productos de calidad en tiempo y en precio.

Algunos estaréis pensando y con razón que sí, que es posible, pero podríais hacerme algunas preguntas que no tienen una respuesta precisamente sencilla:

- ¿Qué pasa si el proyecto está mal estimado en tiempo y/o en dinero o se ha vendido en unas condiciones imposibles?

Pues que la aplicación de la metodología no va a hacer milagros, es decir, probablemente estos problemas en la estimación (o en la venta) darán lugar a un producto con calidad mejorable (cuando no deficiente), tal vez fuera de plazo y que costará mucho que sea rentable para el que lo desarrolla. No obstante, no es un problema de la metodología es un problema de partida que sufren multitud de proyectos y es que no se le otorga al desarrollo de software el valor que le corresponde (y contra eso es una de las cosas que todos los que nos dedicamos a este negocio tenemos que luchar).

- ¿Qué pasa si el cliente o los usuarios no responden?

Pues que tampoco es culpa de la metodología, ese problema se tendría con o sin procesos. La metodología puede proporcionar técnicas para facilitar la obtención de la información y la colaboración que se requiere para el desarrollo del proceso, pero las técnicas no pueden solventar asuntos que son interpersonales, para esto se requiere otro tipo de habilidades y experiencia que pueden facilitar las cosas (pero que no siempre tendrán una barita mágica detrás).

- ¿Metodología implica un mayor coste?

Depende de cómo se mire. Para empezar bien o mal cada empresa, cada equipo de proyecto o cada técnico tiene su metodología para desarrollar un producto, la diferencia con respecto a los procesos que estoy indicando es la formalidad (entendiéndose como algo repetible de la misma manera o similar en proyectos con características comunes), por tanto no se trata de aplicar una metodología o no aplicarla sino de trabajar de una determinada manera y con unos controles.

Una metodología que no se puede aplicar o utilizar en el contexto de un proyecto o de una organización no es una metodología sino un conjunto de papeles con letras impresas que bien pueden servir para escribir en sucio (pero para poco más), por tanto si no es aplicable por el coste que supone o por las características del proyecto concreto donde se va a trabajar el problema está en la selección de la metodología, pero no en el uso en sí de las mismas. Mejor siempre trabajar con procesos, aunque sean pocos, que no utilizarlos o emplearlos de manera incorrecta.

La aplicación de metodologías y la puesta en marcha de controles resta flexibilidad pero, ¿es necesariamente eso malo?, también dará lugar a más productos intermedios (documentación), pero no se trata de rellenar papeles por rellenarlos, sino que los mismos sean un soporte para el posterior proceso de construcción de manera que se tenga mucho más claro que se va a implementar y cómo, con el objeto de que el producto sea lo más mantenible posible (a eso también contribuye una buena codificación, pero no es lo único importante).

Esta forma de trabajar tendrá un mayor coste, pero, ¿no es mejor asumir esto que tener que aplicar después un esfuerzo importante en mantenimientos correctivos o evolutivos?. Estos mantenimientos no son gratis, tienen un coste tanto para clientes como para proveedores, además de las consecuencias que pueden tener en el funcionamiento de los procesos donde se ha implantado.

No es muy popular en la comunidad del desarrollo de software creer en este tipo de cosas y lo respeto, no obstante he creído conveniente exponer mi punto de vista sobre un concepto como es la ingeniería del software en el que creo.

Advertisement

• Bauer
• Crisis del software
• desarrollo de software
• Gestión de Proyectos
• ingeniería del software
• mantenimiento correctivo
• Mantenimiento del sistema de información
• mantenimiento evolutivo
• Métrica
• Métrica v.3
• metodología
• MSI
• procesos
• programación
• software