No he encontrado ningún pdf colgado pero dicen que lo que presentarán esto en las jornadas que organizan en Madrid los días 24 y 25 pero los detalles que pongo abajo parece que no hacen pintar bien el panorama.

Os pongo el resumen que mandaron:

Sobre un total de 20 prácticas clave para la realización madura de pruebas de software, como media las organizaciones implantan 8.
Sólo un 26% de los encuestados afirmaba haber recibido formación específica sobre pruebas
Al diseñar pruebas, los profesionales tienen tendencia a la falta de sistemática provocando
Baja eficacia (como promedio, se prueba el 46% de las opciones del software)
Baja eficiencia (se repiten innecesariamente casos de prueba totalmente equivalentes en valores que oscilan desde un 135% para alta de datos a un 13,8% en pruebas de borrado. el 50% de los casos ejecutaban caminos ya probados por el “tester”)
Desestimar la priorización (tras valorar la importancia y prioridad de los casos, sólo aparece 1 de los más prioritarios entre los 10 caminos más ejecutados y entre los 10 menos probados aparecen 3 de los 10 más prioritarios)
Los factores que más influyen (más del 85% de acuerdo) en que pueda existir una situación mejorable de las pruebas en España son:
o La presión de calendario de las pruebas como última fase del desarrollo
o La tentación de recortes en calidad cuando hay problemas económicos o de retrasos
o La desconexión y falta de aprovechamiento de los productos y diseños de desarrollo para diseñar las pruebas
o La carencia de formación de directivos (para apreciar el potencial de las pruebas), la de los titulados en cuanto a formación específica en la carrera y la falta de formación a los profesionales en las empresas
Los factores menos generalizados (50% de acuerdo) para explicar las deficiencias de las pruebas son:
o Las pruebas constituyen un campo con poco desarrollo y atractivo profesional
o Es una actividad destructiva, con poco atractivo, un fastidio obligatorio
o Los puestos en calidad y pruebas son inestables y no es extraño que desaparezcan para integrar a los profesionales en la plantilla de desarrollo cuando hay problemas en la organización

El tema y la traducción la puedes descargar usando subversion:

svn co http://svn.dlopez.net/wordpress/hemmed-theme/trunk/

El tema debe ser localizable para poder mostrar los mensajes en castellano. Debes poner el fichero es_ES.mo en wp-includes/languages/ y modificar el idioma por defecto en wp-config.php poniendo:

define ('WPLANG', 'es_ES');

Suerte!

Mil gracias!

De todas formas, os voy a poner una cita del Peopleware del Arte de la Guerra:

Hay seis formas de escoger a las personas para ejercer el mando:
- Enriquecerlos y observar si se refrenan de la mala conducta para probar su humanidad.
- Ennoblecerlos y ver si se contienen de la altanería, para probar su sentido de justicia.
- Darles responsabilidades para ver si se contienen del comportamiento despótico, para probar su lealtad.
- Tentarlos para probar su confianza.
- Ponerlos en peligro y ver si no se asustan, para probar su valor.
- Abrumarlos y ver si permanecen incansables, para probar como abordan estratégicamente los problemas.

Es curioso, pero algunas las puedo constatar, tengo un amigo que me ha contado… conyo, espero que no estuviera hablando de mi!

Pues bien, en el paradigma AOP pasa lo mismo, el ciudadano de primer orden es el aspecto o “concern” y los programas se crean a base de definir las interacciones entre los mismos. En HyperJ, que es un primer intento de crear un lenguaje AOP puro, se habla de dimensiones y de “cortes” entre las dimensiones y no hay ninguna dimensión más importante que otra, sus creadores hablan de lo que hasta ahora se ha llamado ”lógica de negocio” como un simple aspecto más.

Podeis ver más sobre esto en el número de octubre de 2001 de Communications of the ACM o en http://www.research.ibm.com/hyperspace/HyperJ/HyperJ.htm

Saludos a todos.

No he podido encontrar los enlaces de los artículos que leí acerca del [mal] uso del XML, pero buscando un poco he encontrado otros, el más representativo es Just say no to XML.

BeanShell creo que es aplicable perfectamente al mundo empresarial, pero reduciéndo su uso a scripts de build o de configuración.

Primero agradeceros por este portal tan interesante sobre esta ingenieria creciente…

Leyendo sobre vuestra tertulia dedicada al AOP tengo que decir que estoy deacuerdo con David. El AOP es una forma mas de hacer OO con la unica diferencia que el codigo es declarado en tiempo de ejecucion del programa (como decia David con un waeving).

Una cosa que no entiendo, pues, es eso que dices, David:
[...]
En muchos artículos comienzan a alarmar del peligro del excesivo uso de XML debido a que no encaja bien con las metodologías que conocemos, y proponen cambiar esto por un lenguaje de scripting imperativo, por ejmplo para Java el BeanShell (que es idéntico a java, pero no se compila, es un script interpretado).
[...]

¿Donde estan esos articulos? Llevo tiempo programando AOP, Hibernate, etc, y nunca encontre ningun articulo de los que dices…

BeanShell, como dicen los creadores es una pequeña extension de Java que se puede utilizar para diferentes cosas (como por ejemplo en el ámbito de la educación), pero realmente dudo que en un ámbito empresarial sea de mucha utilidad…

Un saludo y mucha suerte con la web!