Calidad de software

Mantenimiento informático de calidad Horas ilimitadas Visitas mensuales Sin permanencia Siempre el mismo técnico Puesta a punto inicial

Calidad de software

Durante los últimas semanas me estoy concienciando sobre el tema de la mal llamada calidad del software, en mi opinión la calidad siempre será la misma, porque esta mal llamada calidad de software no pretende mejorar el «ingenio» o eliminar la «torpeza». Pero si que es cierto que bajo «calidad de software» al menos se alojan una serie de técnicas que no pueden ser cuestionadas, y evitan en gran medida el descontrol y la anarquía que suele aparecer en los proyectos medios.

Una vez tomados lo requisitos creo que las herramientas fundamentales para el control del desarrollo de un equipo, son:

  • Un sistema de control de versiones
  • Bugtracker
  • Dailybuild

Control de versiones

Quizás unos de los puntos mas importantes y que, sinceramente, la mayoría de las empresas olvidan, es el sistema de revisiones, por lo que he visto la mayoría se conforman con una carpeta compartida, donde se dejan todos los fuentes (con un copy de toda la vida), luego se añade un sistema de backups, mas o menos fiable, que se realizará todos los dias rezando porque no se necesite utilizar. Como cada programador se encarga de un módulo pues no se producen colisiones por lo que todos contentos. Los errores se comunicaban en post’it, y una vez al mes o cuando toque se hace la compilación conjunta y se crea el instalador, vamos el setup.exe de toda la vida. Este sistema funciona, ¿porque no?

El principal problema esta cuando se comparte el código de verdad, es decir cuando existe varios programadores que manejan una area común, como por ejemplo librerías. En este caso el ultimo en pasar los datos machacaría a los demás. Otro caso seria la recuperación de versiones anteriores, y por supuesto el control de ramas de aplicación, es decir podemos estar trabajando en la version 4.0 beta mientras tenemos la 3.5 como estable, la 4.0 puede ser una rama de la version 3.0 cuando la 4.0 esta en version estable se puede fisionar con la 3.5

Una vez convencidos de la necesidad de un sistema de versiones ahora queda, escojer uno, y como en todo este negocio, cada fabricante tiene el suyo, Sharepoint, cvs, svn, etc., el sistema de revisiones mas extendido era el CVS, ahora es sustituido por subversion o SVN, subversion tiene una mejora importante sobre CVS, que permite el ser montado sobre un servidor apache, de tal forma que el codigo puede ser compartido a traves de un servidor web, convencional. Las actualizaciones de los fuentes se realizan de una forma realmente rápida, y gracias a la herramienta TortoiseSVN, ademas es realmente facil. En principio yo tengo instalado este sistema bajo un servidor apache2, montado en un linux, y bajo una conexion adsl con ip fija, lo que me permite el trabajar en la oficina y fuera de ella.

El segundo punto fue instalar un bugtracker, que no es mas que un punto de encuentro de betatester y programadores, yo instale flyspray, una aplicación de desarrollada para un entorno LAMP, y realmente da buenos resultados.

En tercer lugar desarrolle las dailybuild, las compilaciones diarias, las cuales mediante un script, bastante cañero, permite el compilar, generar el setup up, subir al espacio web, y modificar la página, permitiendo ver los cambios en la nueva versión.

Con todo esto lo que hemos conseguido es un mejor control del proyecto, permitiendo no molestarnos, y dirigir el desarrollo a puntos especificos, pero el proyecto sigue siendo el mismo con la misma calidad, por eso me parece un poco pretencioso el definir los nuevos sistemas como «calidad» del software.

 

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

A %d blogueros les gusta esto: