archivo

Archivo de la etiqueta: ingeniería del software

Un defecto aunque también es una virtud que tenemos los que nos dedicamos a esto, si se realiza de forma moderada y en el momento adecuado, es que tenemos cierta esencia de artista.

En los proyectos en los que trabajamos queremos dejar nuestra impronta, nuestro sello. También es cierto que el proceso de desarrollo de software se presta a ello, ya que tenemos todo un campo donde poder cultivar nuestra capacidad creativa.

Lo importante es ser práctico y que el proyecto salga adelante cumpliendo las expectativas del usuario y desarrollando un software de calidad. Mientras se cumpla esa premisa, es compatible aplicar nuestra creatividad al proyecto.

Por otro lado, en el proceso de desarrollo de software, se pierde mucho tiempo en detalles irrelevantes, en ocasiones provocados por el equipo de proyecto y en otras por los usuarios. ¿Cuántas veces se ha tenido que modificar el diseño de una interfaz de usuario en etapa de desarrollo o una vez puesta la aplicación en producción?, ¿cuántas veces se ha pedido cambiar un color por tal otro?, ¿cuántas veces se solicita cambiar un literal por otro?. No entro en si es sencillo o no realizar estos cambios, lo que sí es importante es que mientras se centre la atención en esto no se enfoca el esfuerzo en lo realmente importante y es que el software funcione y sea de calidad.

Hay una cita de H. W. Kenton, un tanto tremendista, pero que ilustra bien a las claras lo importante que resulta centrarse en lo que realmente importa: “Aunque sin duda hay un elemento artístico en la ingeniería, a nadie le importa de qué color era el puente que se derrumbó y mató a cincuenta personas”.

Harlan D. Miles fue profesor del Instituto Tecnológico de Florida aunque también tuvo una amplia experiencia en el sector privado tanto trabajando por cuenta ajena en IBM como siendo fundador de su propia empresa de desarrollo de software.

Mills destacó por su contribución al campo de la ingeniería del software mediante la integración en la misma de principios estadísticos y matemáticos orientados a la obtención de un software sin errores. Su trabajo fue utilizado en el desarrollo de sistemas de información en sectores críticos como la medicina, comunicaciones y energía.

El IEEE reconoció su trabajo mediante la creación en el año 1999 del premio Harland D. Mills.

Con toda esta experiencia, Mills sabía muy bien lo que decía cuando realizó la siguiente reflexión (traducción libre): “La única manera de que los errores aparezcan en un programa es que el autor del mismo los haya colocado allí. No hay otra forma conocida ya que los programas no pueden provocar errores por sí mismos. Las buenas prácticas tienen como objetivo prevenir la inserción de errores y, cuando eso falla, eliminarlos antes de la realización de las pruebas o cualquier otra ejecución del programa”.

No es que Mills no crea en el testing, sino que considera que hay errores perfectamente evitables antes de esa fase. Adquirir unas buenas prácticas y unos buenos hábitos en la programación (como por ejemplo probar bien lo que se codifica) ahorra esfuerzo, ya que aplazarlo no solo no lo evita sino que en ocasiones lo multiplica, además de incrementarse el riesgo de que algunos de ellos, que pueden ser críticos, lleguen a producción.

Boris Beizer es un autor e ingeniero de software americano (aunque nacido en Bélgica) especializado en el campo de la calidad del software y del testing. Sus primeras publicaciones datan de finales de la década de los cincuenta, aunque su etapa más prolífica fue en las décadas de los setenta y de los ochenta.

El testing es un campo dentro de la ingeniería del software un tanto controvertido. La mayoría de los profesionales consideramos necesarias las pruebas en el proyecto de desarrollo de software, si bien no hay coincidencia en cuanto a la intensidad, los momentos y la metodología.

Soy de la opinión de que no todos los proyectos y sistemas de información deben tener un mismo tratamiento y que independientemente de que exista una cierta metodología en las pruebas, estas deben girar alrededor del testing ágil y del exploratorio.

También soy partidario de que las clases con mayor acoplamiento sean cubiertas mediante pruebas unitarias (no necesariamente desarrollando según técnicas de desarrollo guiadas por las pruebas (TDD)) y que se deben minimizar los efectos colaterales a través de las pruebas de regresión.

En cuanto a los momentos, el testing debe aplicarse desde las etapas más tempranas del software, si bien los actores pueden ser distintos a las pruebas realizadas sobre el producto.

Y como estrategia, la utilización de integración continua permite detectar problemas de carácter unitario y de integración lo antes posible y a reducir los problemas en la fase de implantación.

Boris Beizer realiza la siguiente reflexión (traducción libre): “Una amenaza bien vale mil pruebas”.

Desgraciadamente nos acordamos de un proceso de testing bien realizado cuando ya los errores han salido a la luz y lo peor de eso, cuando su corrección requiere de un esfuerzo considerable, cuando ha impactado gravemente en el negocio o cuando nos crea un problema.

Cuando mayor sea la criticidad del sistema más peso debe tener el proceso de testing y más peso debe cobrar la metodología y sistematización.

David Hillel Gelernter es profesor de informática de la Universidad de Yale y ha escrito numerosos libros y artículos.

Gelernter encuentra la belleza en disminución de la complejidad en el software, tal vez porque es una de las variables más importantes para que un proyecto tenga posibilidades de ejecutarse con éxito, por ello en su libro “Machine Beauty” realiza la siguiente reflexión: “La belleza es más importante en el mundo de la computación que en cualquier campo de la tecnología porque el software es muy complicado. La belleza es la última defensa contra la complejidad”.

Menos es más en la mayoría de los proyectos de desarrollo de software y aproximadamente el 50% de las funcionalidades que se suelen implementar en los sistemas de información no se utilizan o tienen un uso marginal. Además, modelos de datos, arquitecturas y frameworks simples (siempre y cuando sean acordes a la naturaleza del proyecto) ayudan a que el proceso de construcción y evolución natural del software sea más dinámico y llevadero.

Los procesos de la ingeniería del software deben buscar el éxito en la ejecución del proyecto y si añaden complejidad no hacen más que poner obstáculos en el camino. El desarrollo de software es complejo, la clave es no añadir más que la que ya tiene.

Como añadido a la cita anterior, en el mismo libro, David Gelernter comenta lo siguiente: “Los buenos programadores saben lo que es la belleza, los malos no”.

Los problemas del ciclo de vida clásico o en cascada empiezan con los cambios de requisitos en fases posteriores al análisis y estos son inevitables salvo que el sistema que se desarrolle sea pequeño.

Cuando estos cambios ocurren, salvo que el presupuesto sea muy holgado, empieza el desgaste entre proveedor, área técnica del cliente y los usuarios que dará lugar finalmente a un producto y a un proyecto que probablemente no dejará totalmente contento a nadie, ya sea por los costes, los plazos y/o por la calidad final.

El carácter predictivo que tiene este tipo de desarrollos, provoca, sobre todo si ya tienes una cierta experiencia, respeto a los usuarios a la hora de definir los requisitos y a los desarrolladores de ejecutarlos con éxito.

El ciclo de vida del proceso unificado (como por ejemplo RUP) o los ciclos de vida de las metodologías ágiles son adaptativos, están orientados probar soluciones, si no gusta se intenta otra, si solo requiere cambios parciales, estos se llevan a cabo. Hay que perder el miedo a especificar requisitos y a ejecutar soluciones, de esta forma es como se consigue que las funcionalidades, que los módulos se ajusten cada vez más a las expectativas del usuario.

Esto tiene su coste, la diferencia es repercutir parte del coste de mantenimiento en el propio proceso de desarrollo, al final, este mayor presupuesto en el desarrollo saldrá barato, ya que no es lo mismo evolucionar sistemas complejos ya en producción, que ir madurando poco a poco los mismos.

Mark A. Ardis es un profesor universitario americano especializado en el área de la ingeniería del software. Cuenta con una importante experiencia académica en diferentes instituciones universitarias americanas, además de haber trabajado en el pasado como contratista de determinados departamentos del gobierno americano y formar parte del área de investigación en Bell Laboratories.

Una cita de este autor, constituye el “One Page Principle” y viene a decir que: “Una {especificación, diseño, procedimiento, plan de pruebas} que no se ajuste a una página de de 8.5 por 11 pulgadas no puede ser comprendida”.

Para conseguir ese objetivo es necesario descomponer en unidades más simples cada uno de esos entregables y centrarse en describirlos de una manera clara y concisa.

El hecho de RUP siga un ciclo de vida que se puede considerar iterativo e incremental no implica que se le pueda considerar una metodología ágil y eso que sobre el papel podría considerarse que verifica los principios del manifiesto ágil.

Por ese motivo quien considere que RUP es ágil tienen una buena coartada. Se esté o no de acuerdo con que se considere una metodología ágil, lo que no deja dudas es que se trata de una metodología de carácter adaptativo, fruto de su vocación iterativa, incremental y unificada.

¿Por qué no lo considero una metodología ágil? Principalmente porque el marco de trabajo que define, implica liberaciones muy tardías en entornos de producción. Es cierto que en la etapa de construcción en cada iteración se pueden liberar versiones en entornos de desarrollo (o incluso preproducción) y que en las etapas finales de la construcción se pueden incluso hacer implantaciones en producción (si bien esta es la responsabilidad principal de la siguiente, la de transición).

Es decir, los usuarios seleccionados para participar en el proyecto de desarrollo de software, pueden proporcionar feedback en todas las etapas, siendo el más importante el que pueden proporcionar cuando están probando/trabajando con el sistema. Sin embargo, este feedback cuando resulta realmente valioso es cuando se está haciendo un uso real del sistema en un entorno de producción.

Esta característica, junto al hecho de que RUP plantea un marco de trabajo donde el proceso cobra una importancia especial, hace que la respuesta al cambio no sea ágil, ya que principalmente en la etapa de transición es donde se itera sobre el producto para ir adaptando el sistema a las necesidades y expectativas del usuario en aquellos aspectos en los que no se ha acertado en fases anteriores o como consecuencia de cambios en el negocio que se hayan producido durante el proceso de desarrollo.

Estas iteraciones se hacen sobre la versión del producto en la que se ha trabajado durante el ciclo de vida RUP, por lo que el esfuerzo necesario para hacer las modificaciones es mayor y en consecuencia el tiempo que tarda el usuario en poder disfrutar de ellos en el entorno de producción.

También se puede plantear el desarrollo como una secuencia de RUP, de manera que el proceso de desarrollo sea más liviano, de esta forma sí que se acercaría más a las metodologías ágiles, sin embargo, soy de la opinión de que RUP en origen tenía un enfoque más tipo big bang, orientándose a la entrega de una versión finalista del producto.