Mi espacio

Version Naming, Software Versioning o Sistemas de Versionado, es lo que se conoce como el proceso con el que identificamos de forma única el estado de los fuentes de un proyecto. Obviamente puede hacerse extensible no sólo al software, sino también a un documento de texto. Según los sistemas de gestión de la calidad debe incluirse un histórico de cambios.

¿Qué objetivos pretende cubrir un sistema de versionado?

1. Identificar de forma sencilla el estado de los fuentes. Esa identificación estará asociada a un instante de tiempo
2. Establecer una codificación que permita distinguir unas versiones de otras
3. Informar sobre qué contiene la versión

Existen muchas propuestas y cada una de ellas se adecua a unas necesidades. Nosotros hasta la fecha usábamos una muy conocida basada en:

• alpha
• beta
• Releases Candidate
• X.Y.Z

La versión alpha es una versión completa desde un punto de vista funcional. El equipo de proyecto debería ser capaz de justificar que los requisitos y expectativas detectadas se han alcanzado. Los que nos dedicamos a esto sabemos que es prácticamente imposible, especialmente en proyectos de más de 6 meses. La entrega oficial de una versión es un punto de inflexión en la relación entre el cliente y el proveedor. Está claro que el proveedor le está transmitiendo al cliente que para el proyecto se encuentra en su etapa final y que es el momento de ir cerrando los temas pendientes (artefactos documentales, sesiones de formación, etc).

La versión beta constituye otro momento importante en la vida del proyecto. Tras la entrega de la versión alpha se recoge comentarios, opiniones, peticiones de cambio, “…es que yo pensaba, yo creía que…” (por ambas partes), el departamento de sistemas añade sus “…esto lo quiero así, si hibernate te genera el DDL eso me da igual…“, y evidentemente si no quieres que el proyecto se te vaya en costes, negocias. Personalmente creo que es una -falsa- negociación porque como proveedor comienzas a ver el final y tu mayor deseo es implantar el proyecto y verlo como ayuda a los verdaderos usuarios finales.

Y luego vienen las versiones RCx, que junto con la versión beta, modelan las distintas iteracciones cliente-proveedor. Así, hasta llegar a la versión 1.0.0 donde se hace entrega oficial de los fuentes y corresponde con la versión que pasa a producción. A partir de ahí, comienza el soporte y mantenimiento que dará lugar a:

• 1.0.Z: Resolución de incidencias sobre la versión 1.0.0
• 1.Y.0: Si aumenta la Y, la Z se pone a cero e implica que se han incorporado mejoras y probablemente resolución de incidencias
• Z.0.0: Conlleva lo anterior pero además implica cambios importantes a múltiples niveles (diseño, funcionalidades, UI, etc..)

Esto es, de forma muy resumida, lo que venimos usando desde hace 2 años. Muy relacionado con otras prácticas de nuestra metodología nos hemos visto obligados a realizar una pequeña modificación e incorporar el concepto Partial Delivery:

1. No están reflejadas en el roadmap del proyecto, no constituyen ningún hito
2. Normalmente vienen originadas por una petición externa al equipo de proyecto
3. Están referenciadas en la herramienta de gestión de proyecto
4. Se podrían haber sustituido por conceptos como revisión propios de los S.C.M. pero resulta más sencillo trabajar con alpha-PD1 que con rev657.

Por aclarar algunos puntos:

1. En nuestro entorno de despliegue, y como parte de las actividades de integración continua, el estado de los fuentes es referenciado como 1.0.0-SNAPSHOT-r2203 o 1.0.0-DEV-r2203. Para la revisión usamos buildNumber.
2. Sólo versionados aquello que necesitamos referenciar.

En ciertos proyectos, por su diseño y base tecnológica, incorporamos otras prácticas. Por ejemplo, en aquellos con un alto índice de modularidad  cada módulo mantiene su propio versionado y las entregas incluyen un documento (o MasterBuild) en el que se detalla o define la entrega. Como ejemplo podemos ver aquellos que se basan en OpenCms o Drupal.

Y tú, ¿Cómo llevas a cabo este proceso?

La verdad es que ha costado, pero por fin, puedo anunciar el nacimiento de QABox. Aun tenemos que resolver ciertos aspectos técnicos pero eran tantas las ganas que no hemos podido esperar más. Espero y deseo que en breve, tengáis nuevas noticias con respecto a esta iniciativa.

Hace unos instantes he recibido un correo de la organización de ExpoQA diciendo que han publicado el material de las ponencias.

Como ya hiciera el año pasado, este año asistiré a una nueva edición de expo:QA. Este año espero escribir una pequeña crónica de los dos días que asistiré. El programa de este año -parece- que incluye contenidos más cercanos a nuestro día a día. El año pasado me quedé con mal sabor de boca, especialmente porque todo el aseguramiento de la calidad consistía en adquirir herramientas carísimas y las experiencias reales brillaron por su ausencia, y las que hubo, pertenecían a sectores (industriales, banca, etc…) que se escapan de mi alcance.

Recientemente hemos entregado a un cliente una aplicación software dentro de un proyecto que está a punto de terminar. Sólo queda cerrar algunos flecos que no dependen directamente de nosotros, sino del propio cliente. El proyecto era pequeño:

• 5 meses en total
• 4 meses desarrollando la aplicación
• 1 Jefe de proyecto, 1 desarrollador del lado del cliente, 2 desarrolladores JEE y 1 asegurador de la calidad

Para la construcción hemos contado con:

• Marco tecnológico Java: Spring framework, Eclipse Birt, Hibernate
• ExtJS
• DEIN – Ecosistema Software (de esto ya os hablaré)

Me gustaría contar algunas lecciones que hemos aprendido:

1. Nos es conveniente homogeneizar los entornos de desarrollo local de todos los miembros del equipo. Aunque el cliente nos indique cuál es su entorno de producción y eso quede reflejado en los requisitos no funcionales del análisis, es altamente aconsejable la disparidad. Es una forma muy simple se disminuir riesgos y asegurar un mayor nivel de calidad. Concretamente en este proyecto hemos usado:
   1. Ubuntu, Eclipse, Jetty, JDK 1.5 (entorno de desarrollo local)
   2. Windows XP, Eclipse, Tomcat JDK 1.6 (entorno de desarrollo local)
   3. Debian, Tomcat, Apache, JDK 1.5 (entorno de despliegue virtualizado que DEIN proporciona)
2. Las tareas de análisis nunca terminan. Cuando el analista decide que hay una versión estable de los requisitos y se ponen en marcha las tareas de implementación, se activa un proceso iterativo entre el diseño-implementación y el análisis. El objetivo final para el cliente es que lo que le entreguemos satisfaga sus espectativas, sin embargo, nosotros compartimos ese mismo objetivo y además tenemos que asegurarnos de que lo construido y lo analizado está sincronizado y se corresponden. ¿Por qué? Porque aunque sean desarrollos a medida (llave en mano) es probable que surjan ampliaciones, revisiones, etc. y por eso mismo tenemos que ser consecuentes con lo que hacemos. No es la primera vez que me encuentro un documento de análisis perfectamente maquetado con una página inicial en la que se indica que lo validó tal persona hace un año y recientemente se ha publicado una versión.
3. Es importantísimo hacerle ver al cliente cuánto cuestan los cambios y todo lo que adicionalmente solicita. Entiendo que es una tarea complicada, pero ahí está la destreza de un buen jefe de proyecto. Lo que no podemos hacer es admitir cambios y mejoras durante la evolución del proyecto con el fin de mejorar la experiencia de los usuarios finales, y que luego, cuando el proyecto está terminando te inunden en procesos eternos llenos de burocracia.
4. En tu planificación prioriza al máximo el obtener una primera release que puedas mostrar a los usuarios finales. Haz todas las entregar parciales que puedas y la disponibilidad del cliente permita. En este proyecto concretamente, el cliente ha tenido la oportunidad de ver todos los avances de forma diaria. DEIN se encargaba se desplegar todas las noches un SNAPSHOT del proyecto en el entorno de despliegue, que por supuesto estaba disponible para el cliente.
5. Establece sesiones de trabajo (preferiblemente, semanalmente) con todos los miembros del equipo. Aprovecha esta sesiones de trabajo para hacer una puesta en común de perspectivas, dudas, aclaraciones, consideraciones, propuestas, etc…
6. Procura que todos tus proyectos tengan algo de I+D+I. Disponer de un departamento de verdad de I+D+I no es sencillo y requiere inversión, pero cuando no se tiene esa opción, algo debemos hacer. Cuidado con los experiementos en proyectos pequeños, es muy sencillo incumplir en la planificación si algo no sale todo lo bien que esperábamos.

Supongo que la lista podría continuar, pero son los que puedo contar y pueden ser útiles. En cuanto me autoricen, publicaré algunas capturas de pantalla (y con suerte un screencast) sobre el proyecto.

Aquellos que me soportan todos los días en el trabajo saben que soy un maniático de los detalles. Soy de las personas que sufre si los fuentes de un proyecto no están correctamente tabulados o si los terminadores de línea no son los correctos. Sí, sí, lo sé, Opina 1.x me hace sufrir, pero poco a poco lo voy organizando todo, especialmente en Opina 2.x.

Algo que debe formar parte de todo buen ecosistema software que se precie es un conjunto de buenas prácticas que recomienden cómo debemos usar las herramientas que lo forman. En este caso hablaremos de subversion, el sistema de control de versiones que uso. Gracias a las propiedades de subversión podemos controlar:

1. Los terminadores de línea
2. Los tipos mime de los archivos
3. Los archivo que siempre ignoramos y que proyecto tras proyecto tenemos que ignorar. ¿El directorio /target tal conocido por aquellos que usan Maven? ¿El directorio /build?

Pues bien, para evitar que cada vez que se añada un archivo tengamos que configurar sus propiedades svn, que mejor forma que tener todas esas propiedades bien definidas en un archivo y que se usen en el ecosistema.

A continuación se muestra el archivo de configuración que estoy usando en Opina para las propiedades svn:

#
# Opina: gestor de encuestas
# Copyright (C) 2005-2008 Opina Development Team
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of version 2 of the GNU General Public
# License as published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA
#
# $Id: opina-svn-properties 1842 2008-10-09 19:46:18Z recena $
#

[auto-props]
*.sh         = svn:executable;svn:eol-style=native;svn:keywords=Id
*.bat        = svn:mime-type=text/plain;svn:eol-style=CRLF
*.bmp        = svn:mime-type=image/bmp
*.class      = svn:mime-type=application/java
*.doc        = svn:mime-type=application/msword
*.exe        = svn:mime-type=application/octet-stream
*.gif        = svn:mime-type=image/gif
*.gz         = svn:mime-type=application/x-gzip
*.jar        = svn:mime-type=application/java-archive
*.jpg        = svn:mime-type=image/jpeg
*.jpeg       = svn:mime-type=image/jpeg
*.pdf        = svn:mime-type=application/pdf
*.png        = svn:mime-type=image/png
*.tgz        = svn:mime-type=application/octet-stream
*.tif        = svn:mime-type=image/tiff
*.tiff       = svn:mime-type=image/tiff
*.zip        = svn:mime-type=application/zip
*.txt        = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.xml        = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Id
*.xsd        = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Id
*.xsl        = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Id
*.wsdl       = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Id
*.htm        = svn:mime-type=text/html;svn:eol-style=native;svn:keywords=Id
*.html       = svn:mime-type=text/html;svn:eol-style=native;svn:keywords=Id
*.css        = svn:mime-type=text/css;svn:eol-style=native;svn:keywords=Id
*.js         = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.jsp        = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.txt        = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.java       = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.properties = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.sql        = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id

Una vez que tenemos configuradas nuestras propiedades tenemos que hacer dos cosas:

1. Indicarle a nuestro cliente de subversion que estas propiedades existen y tienen esos valores
2. Indicarle a nuestro cliente de subversion que las tenga en cuenta.

En mi caso uso subversive como cliente de subversion, es un plugin para Eclipse. Para importar estas propiedades hacemos lo siguiente: Windows > Preferences > Team > SVN > Properties Configuration > Automation properties > import. Una imagen mejor, ¿no?

Ahora debemos localizar el archivo de configuración que el cliente usa:

~/.subversion/config (Linux)
%USERPROFILE%\Application Data\Subversion\config (Windows)

Ahora cambiados dos propiedades en ese archivo de configación

global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store build dist target
enable-auto-props = yes

Espero que esto ayude un poco a aquellos desarrolladores que son un poco despistados y se olvidan de configurar convenientemente las propiedades svn. Ahora el siguiente paso es hacer hook (pre-commit) que se encargue de que las cosas están bien configuradas, y en caso contrario, envíe un correo al QA para repartir collejas.

Después de 8 años vinculado al desarrollo de software tengo que reconocer que cualquier instalación de una nueva versión de un software supone un reto y no está exento de sorpresas.

El diseño e implementación de tests son actividades muy importantes y necesarias en el ciclo de vida de un proyecto software. Estas actividades forman parte de una disciplina denominada aseguramiento de calidad del software. Recientemente he llegado a la conclusión de que son esos pequeños detalles, que normalmente se dejan pasar por alto, los que más tiempo nos hacen perder a la hora de realizar un paso a producción. Realizar un paso a producción tiene sus connotaciones, y una de ellas es que normalmente o se realizan en las instalaciones del cliente o las realiza el propio cliente. Podríamos considerar en lugar del cliente, al usuario final para así dejar a un lado la parte empresarial de la profesión.

Con intención de recoger esos tests que nos adviertan de esos pequeños detalles, he preparado el siguiente listado de tests que incluiré por regla general en mi plan de tests para proyectos Java:

1. Comprobar que la JVM que hay configurada en el sistema operativo es válida según el catálogo de requisitos no funcionales. Eso no evitará que si nuestra aplicación se despliega sobre un contenedor o servidor de aplicaciones, éste esté configurado con una JVM distinta a la del S.O., pero esta situación es menos frecuente.
2. Si nuestra aplicación necesita una base de datos, comprobar que la configuración es correcta y que la versión y base de datos están recogidas en el catálogo de requisitos no funcionales.
3. Realizar una comprobación como la anterior para servicios como directorio activo, correo electrónico, etc. De esta forma, podremos descartar problemas de integración con sistemas externos a nuestro software.
4. Si nuestro software necesita escribir en el sistema de ficheros, comprobar que disponemos de los permisos correspondientes.
5. Si nuestro software necesita acceder a internet o fuera de una red de área local, realizar la correspondiente comprobación.

Estos tests son muy simples pero nos ayudarán a detectar posibles problemas de integración con el entorno donde nuestro software se tiene que instalar. ¿Alguna sugerencia para añadir a estas pruebas de carácter muy básico?

Hace algunas semanas conocí el blog de John Ferguson Smart. Llegué a él de casualidad, como otras muchas veces mientras navegamos por la red en busca de información. Me sorprendió gratamente al ver que era el autor del libro Java Power Tools. Cuando vi el índice del libro me gustó mucho porque en él se habla de todas esas herramientas, buenas prácticas, metodologías y procesos que forman parte de mi trabajo.

John tiene una empresa llamada Wakaleo Consulting en la que ofrece servicios profesionales sobre:

• Software Development Environment
• Enterprise Java Kickstart
• Training, Mentoring and Coaching

Hace algún tiempo comentaba algo sobre aquellas empresas que ofrecen servicios muy especializados sobre procesos de construcción de software, metodologías, buenas prácticas, herramientas como Maven, PMD, etc. Pues Wakaleo parece ser otra de ellas. Me sigo preguntando si estas empresas tienen cabida en el mercado español…

John ha publicado las transparencias que ha usado en una de sus últimas ponencias en las que habla sobre JUnit.

La verdad es que en la nueva versión de Opina comenzamos a usar JUnit 4 pero ahora estamos evaluando TestNG y el cambio me ha gustado mucho. Personalmente no fui el promotor del cambio, sino mi compañero José María. Todo vino a raíz de necesitar hacer una provisión de datos en la que hemos usando XStream y poder configurar el orden en el  que se ejecutan las pruebas. Con independencia de que también hemos organizado las pruebas en grupos para darle forma a las operaciones CRUD que usamos en nuestras pruebas unitarias.

Antes de comenzar me gustaría comentar que la palabra distribuible está entre comillas porque la RAE parece que no la reconoce, sin embargo, creo que mucha gente la usamos. Este pequeño post lo he clasificado dentro de las categorías Herramientas y Software QA que tengo definidas en mi blog. Lo que justifica este hecho es que hablaré de Apache Maven y sobre cómo mejorar ciertos procesos típicos en la vida de un proyecto software. Para ello hablaré de los “distribuibles”, empaquetados, ensamblados o como se quieran llamar a esas estructuras (comprimidas o no) de directorios y archivos que se usan dentro del marco tecnológico JAVA como son los JAR, WAR, AAR, EAR, etc.

En esas estructuras de directorios normalmente encontramos ficheros compilados (p.e, .class), archivos de propiedades (p.e, .properties), archivos de configuración (p.e, .xml), recursos gráficos (p.e, .png), metainformación (p.e, manifest.mf) y algunos otros más. Personalmente me gustaría destacar todos aquellos archivos que formen parte de la configuración de una aplicación. Las configuraciones más comunes son las referentes a la conexión de base de datos, sistema de correo, sistemas LDAP, etc.

Una muy buena aproximación para mejorar la facilidad de mantenimiento, automatización y personalización de estos “distribuibles” es usar Maven y sacarle partido a los distintos plugins que existen (packaging types / tools) y la gestión de perfiles. Con esto podremos conseguir generar el WAR de nuestra aplicación web configurado para el entorno de producción de nuestro cliente. Bastará con realizar un proceso como el siguiente:

1. Realizar un export del sistema de control de versiones correspondiente a la versión que se desee, que entiendo que estará etiquetada en directorio tags de nuestro repositorio.
2. Dar de alta un perfil con la configuración del entorno que nuestro cliente nos ha facilitado.
3. Ejecutar algo similar a: mvn package -P oracle -Denv=client-dev
4. Desplegar, manual o automáticamente, nuestro WAR (artefacto) donde corresponda.

Doy por supuesto que los miembros del equipo de desarrollo estarán muy familiarizados con la generación de estos distribuibles, sin embargo, son otros perfiles los que, durante el desarrollo del proyecto y/o tras su finalización, tendrán que continuar con su soporte, mantenimiento y evolución. Un ejemplo con el que muchos se pueden sentir identificados es el típico proyecto de llave en mano para un cliente que nos encarga algo a medida. En ese contexto, si el cliente nos demanda que le enviemos un SNAPSHOT para que su personal vaya haciendo pruebas, ¿Qué “distribuible” preparamos?

Es muy frecuente que si se trata de un proyecto software, haya sido un departamento, área o división de desarrollo quien nos haya realizado el encargo. Con esto quiero decir, que el perfil que va a recibir nuestro “distribuible” es probable que con unas simples instrucciones sea capaz de generar el “distribuible” apropiado a partir de un export del repositorio. Ahora bien, no basta con hacer un export, comprimirlo y enviarlo al cliente con las instrucciones, entre otras porque en el repositorio es muy probable que haya información sobre nuestros entornos de desarrollo, múltiples perfiles configurados o simplemente, información que no es útil para el cliente y que únicamente provoca ruido. Con lo cual, parece razonable pensar que vamos a necesitar un “distribuible” con las fuentes de nuestro proyecto que, acompañadas de una guía de instalación y configuración, permitan que el propio cliente pueda ir asumiendo estas tareas que tarde o temprano serán de su plena responsabilidad.

La opción planteada me parece lógica. El cliente nos demanda las fuentes del proyecto, nosotros se las entregamos con los archivos justos y precisos que necesitan para la configuración, pruebas unitarias/integración y la posterior generación del WAR, JAR, AAR o el que corresponda, que se desplegará en el entorno correspondiente.

Con la intención de dar un pasito más y pensando en los perfiles del departamento, área o división de infraestructuras, creo que agradecerán si les ahoramos hacer un export, tener instalado maven, tener instalado el JDK correspondiente y otros pequeños detalles que pueden hacer que algo fácil y mecánico, se retrase durante días. En prácticamente todas empresas e instituciones que conozco es el personal de sistemas o infraestructuras quien verdaderamente realizara los despliegues en los entorno de producción, por lo tanto, nos interesa facilitar al máximo las cosas.

Entiendo que para un administrador de sistemas le resultará más cómodo descomprimir un archivo comprimido (zip, tar.gz, etc.), editar el archivo de configuración que estará documentado en la correspondiente guía de la que antes hablaba y colocar la estructura de directorios y archivos en el lugar correspondiente para su despliegue. Este nuevo caso nos encontramos con que necesitamos preparar un “distribuible” con los binarios de nuestro proyecto.

Son muchas las circunstancias que puede hacer que el administrador del servidor de aplicaciones del cliente necesite volver a desplegar una aplicación determinada, como por ejemplo, cambios en la configuración de red, DNS, modificaciones en las credenciales (usuarios/contraseñas), migraciones, etc, ¿En todas esas situaciones es necesario que haya un desarrollador presente? Si las cosas se hacen bien, podemos ahorrarnos mucho trabajo. Tengo que reconocer que la realidad es otra, pero lo bueno es saber que existen otras formas de hacer las cosas.

Para concluir me gustaría añadir que aparte de lo que podamos generar en nuestra fase de empaquetado (package) y que además lo tenemos automáticamente con Maven, es muy recomendable preparar al menos otros dos “distribuibles” adicionales, uno con los fuentes y otro con los binarios. Para ello es de gran utilidad el plugin de Maven Assembly. Como me he extendido demasiado, aprovecharé otro post para poner algún ejemplo con este plugin. En Opina lo usamos para generar opina-bin-1.0.8.zip, que es el binario de la versión 1.0.8 de Opina que está listo para ser descargado, descomprimido, configurado y desplegado.

En esta ocasión escribo para comunicar que se ha creado una nueva lista de correo para tratar temas relacionados con ecosistemas software basados en herramientas con licencias de código abierto. La lista de correo acaba de ser creada y esperamos que sea bien aceptada por la comunidad de desarrolladores. Para más información sobre la lista de correo:

http://groups.google.com/group/ecosistemas-software

Particularmente mi aportación estará centrata en las herramientas con la que tengo experiencia, sin embargo, tengo mucho interés por conocer otras configuraciones de ecosistemas software. Esas herramientas son Maven, Archiva y Continuum, todas ellas de Apache Foundation.

ExpoQA son unas jornadas anuales que comenzaron a celebrarse en el año 2004. En su cuarta edición, el programa de conferencias resulta atractivo. Estas jornadas están compuestas no sólo por conferencias sino que a los días 29 y 30 de noviembre, les preceden 3 días de cursos.

Viendo la información publicada sobre las ediciones anteriores -creo- que este año es el primero en el que hacen un hueco a la accesibilidad y usabilidad. Hablar del aseguramiento de la calidad del software sin hablar de accesibilidad y usabilidad me parece un error.

Si la agenda lo permite y me autorizan, me gustaría mucho asistir.

Aprovecho esta entrada en el blog para inaugurar una nueva categoría de contenidos, Software QA. Es un campo en el que siempre me he sentido muy cómodo e interesado quizás debido a lo detallista, cuidadoso y organizado que me gusta ser con las cosas que hago. Aunque bueno, no siempre se pueden hacer las cosas como uno quiere.

Es para mi un placer informaros sobre un evento de Software QA totalmente gratuito. Algunos datos importantes sobre el evento:

FECHA:

29 de mayo de 2007

LUGAR:

HOTEL MELIA COLÓN
CANALEJAS, 1 SEVILLA
ESPAÑA – 41001

A continuación tenéis la información del díptico con el que se está publicitando el evento:

El aseguramiento de la calidad del software (Software QA o SQA) ha sido típicamente un paradigma en torno al cual los consumidores de eSolutions han volcado sus expectativas, recibiendo generalmente productos cerrados dentro de los cuales es imposible vislumbrar
marcos de referencia, metodologías, procedimientos, etc, con los que asegurar la calidad del software.

En GMV entendemos que SQA debe ser concebido como un requisito intrínseco a cualquier desarrollo que se afronte y no como un elemento de valor añadido, motivo por el cual constituye por sí mismo una de nuestras líneas de trabajo fundamentales.

Utilizando como base tanto la experiencia acumulada en el desarrollo de productos software propios o soluciones a medida según las exigencias del cliente, como las labores de I+D que se realizan a nivel interno, hemos definido una infraestructura sólida sobre la que afrontar nuevos retos de forma más eficiente. Convencidos de los beneficios que se están obteniendo creemos que es el momento de compartir nuestras experiencias y reflexiones al respecto.

En este seminario, GMV le invita a conocer su visión acerca de la importancia de SQA para minimizar riesgos y maximizar la calidad y la ransparencia de los productos resultantes. Adicionalmente, se expondrán una serie de buenas prácticas, metodologías y herramientas concretas que nos están permitiendo incrementar nuestra eficiencia y mejorar la satisfacción de nuestros clientes.

Dado que el número de plazas es limitado, le rogamos nos envíe su solicitud a la dirección o teléfono que abajo le indicamos.

RESERVAS: marketing-sgi@gmv.com / +34 954 088 060

GMV SOLUCIONES GLOBALES
INTERNET, S.A.
OFICINAS SEVILLA
Avda. Américo Vespucio
Edif. Cartuja. Bloque E -1ª Pta
41092 – Sevilla
Tel: +34 9954 088 060
Fax: +34 954 081 233
infosgi@gmv.com
www.gmv-sgi.com

En el díptico también se ha publicado la agenda del evento:

9:30h – 10:00h: Recepción, entrega de documentación y café

10:00h – 10:15h: Introducción a GMV

Ponente: Miguel Hormigo, Director de la Delegación de Andalucía, GMV-SGI

10:15h – 11:00h: Aseguramiento de la calidad: una aproximación cualitativa

Ponente: José M. Palacio, Responsable de SQA de la Delegación de Andalucía, GMV-SGI

11:00h – 12:00h: ¿Y ahora qué? El día a día

Ponente: Manuel Gómez, Responsable de desarrollo de la Delegación de Andalucía, GMV-SGI

12:00h – 12:30h: Pausa – Café

12:30h – 13:30h: Modelando la calidad con software libre

Ponente: Manuel J. Recena Soto, Responsable de Innovación de la Delegación de Andalucía, GMV-SGI

13:30h – 14:00h: Demostración práctica

Ponente: Manuel J. Recena Soto, Responsable de Innovación de la Delegación de Andalucía, GMV-SGI

14:00h: Cóctel

Sin intención de desvelar los secretos de las ponencias simplemente daros algunas palabras clave: metodología, procedimientos, buenas prácticas, sistemas de control de versiones, seguimiento de incidencias y errores, procesos de construcción, pruebas unitarias, pruebas funcionales, pruebas de sistemas, integración continua, etc… el resto se desvelará durante el evento.