Luis Ochoa

 El pasado 6 de julio de 2.010 entro en vigor la nueva Ley 15/2010 por la que se establecen medidas de lucha contra la morosidad en transacciones comerciales. La ley fundamentalmente establece una serie de limitaciones para el cálculo de la fecha de vencimiento de las facturas con el objetivo de reducir los periodos medios de cobro.

 Entre las medidas más destacadas tenemos:

• Cálculo de la fecha de vencimiento tomando como fecha de partida la fecha de entrega de la mercancía o de los servicios prestados.
• No son válidos aquellos acuerdos que excluyen del cálculo del vencimiento los periodos vacacionales.
• Hasta el 31/12/2011 el vencimiento máximo no debe superar los 85 días
• Desde el 1/1/2012 hasta el 31/12/2012 no se deben superar los 75 días
• Desde el 1/1/2013 no se deben superar los 60 días
• Para los productos alimentarios frescos y los perecederos, se establece desde la entrada en vigor de la ley, un máximo de 30 días desde la entrega de la mercancía.

 Obviamente todas estas medidas son de aplicación para los nuevos acuerdos o contratos comerciales que se firmen desde la fecha de la nueva ley, por tanto no quedan afectados todos aquellos acuerdos que estaban en vigor.

 ¿Cómo afecta todo esto a una implantación de JD Edwards?

•  Los programas de impresión de facturas y de actualización de ventas calculan el vencimiento en función de la fecha de factura, por tanto habría que modificar dichos programas para que tuvieran en cuenta la fecha de entrega para el cálculo. En ese punto es muy importante conseguir que la fecha de entrega de la mercancía se grabe correctamente en el campo adecuado de la base de datos de JD Edwards, para todas las transacciones que entren en el sistema, no sólo las manuales si no también las de interfase y por EDI.
• Habría que reparametrizar todas las condiciones de pago, teniendo especial cuidado con aquellas que incluyen días fijos de pago.
• Habría que revisar la parametrización de la facturación cíclica para adaptarla a la nueva ley.

 No es una gran cantidad de trabajo, pero es necesario hacerlo en el menor plazo posible de tiempo.

 El texto completo de la nueva si necesita consultarla, lo puede encontrar en http://www.boe.es/boe/dias/2010/07/06/pdfs/BOE-A-2010-10708.pdf

Roberto Andrés

Además nos encontramos con un problema humano importante. Los diseñadores de los sistemas de software se han formado habitualmente por experiencia desde puestos de desarrolladores, en ocasiones compartiendo ambas tareas hasta que en su progresión a diseñadores puros deben dedicarse por completo a esa faceta, no teniendo tiempo para programar. Nosotros hemos cambiado con el tiempo, pero invariablemente las herramientas de desarrollo y los sistemas sobre los que se implantan estos han cambiado también e incluso más rápidamente que nosotros. Por un lado habremos perdido de vista todos estos cambios tecnológicos a la vez que también la proximidad e incluso en ocasiones el respeto por aquellos que programan.

No vamos a ahondar en estas cuestiones, pero todos sabemos que están presentes y que crean tensiones dentro del equipo.

 Aun así, vamos a suponer que seremos capaces de manejar estas relaciones del equipo de trabajo (sin romperlo!), aún así tendremos el problema de los requerimientos cambiantes.

Lo más sorprendente de estos requerimientos cambiantes es que a día de hoy alguno de los miembros de casi cualquier equipo de desarrollo se sigue sorprendiendo de que surjan estos requerimientos cambiantes ya que todos sabemos que están ahí desde el comienzo de los tiempos. Hasta Dios diseño el mundo en 6 días y desde entonces no ha parado de detectarle errores y ponerle parches.

Poniéndonos de nuevo serios, estos cambios se producen por múltiples factores; una falta de comunicación o una comunicación incorrecta en el equipo de desarrollo, falta de entendimiento del problema o simplemente en la mayoría de los casos a un cambio de la lógica de negocio, cambio que se da más veces de lo prevista y a la que ninguna técnica de diseño puede anticiparse. Por otra parte, la existencia de cambios previsibles y nuestro deseo de anticiparnos a ellos, pueden devenir en mayores problemas que aquellos que queremos prevenir.

De esta manera se establecen los Métodos Ágiles como métodos orientados principalmente al equipo de trabajo y no al proceso en sí,  de manera que intentamos generar orden en el caos a la vez que no perdemos nuestro precioso y escaso tiempo en generar documentación excesiva y en ocasiones inútil.

A partir del año 2001 los miembros más destacados de este movimiento se reunieron y adoptaron el nombre de Metodologías Ágiles, a la vez que formaron la Alianza Ágil para promover estos tipos de desarrollos, creando un manifiesto y unos principios como base para la estandarización de estos tipos de diseño, que recogen la esencia de la Metodología:

Manifiesto por el Desarrollo de Software Ágil

Estamos descubriendo mejores maneras de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:

• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación exhaustiva
• Colaboración del cliente sobre negociación de contrato
• Responder al cambio sobre seguir un plan

Esto es, mientras en los artículos de la derecha hay valor, valoramos más a los de la izquierda.

Los doce principios:

• Nuestra mayor prioridad es satisfacer al cliente con la liberación oportuna y continua de software valioso.
• Le damos la bienvenida a los requisitos cambiantes, aun ya avanzado el desarrollo. Los procesos ágiles utilizan el cambio para la ventaja competitiva del cliente.
• Liberar software funcionando frecuentemente, de un par de semanas a un par de meses, de preferencia en la escala de tiempo más corta.
• La gente de negocios y los desarrolladores deben trabajar juntos diariamente durante todo el proyecto.
• Construir proyectos con individuos motivados. Déles el ambiente y soporte necesario, y confíe en que harán su trabajo.
• La manera más efectiva de intercambiar información en el desarrollo es la conversación cara a cara.
• El software funcionando es la medida primaria de progreso.
• Los procesos ágiles promueven el desarrollo sustentable. Los patrocinadores, desarrolladores y usuarios deben ser capaces de mantener un paso constante indefinidamente.
• La atención continua a la excelencia técnica y al buen diseño mejoran la agilidad.
• La simplicidad –el arte de maximizar la cantidad de trabajo a no realizar– es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos auto organizados.
• A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, entonces ajusta su desarrollo acordemente.

En el próximo artículo profundizaremos en las principales características de las Metodologías Ágiles.

Juan Sáenz de Tejada

En estos momentos de incertidumbre económica, la formación interna es uno de los grandes retos que las empresas deben afrontar en los próximos meses.  Según los últimos datos de una prestigiosa consultora, cuatro de cada diez empresas concluyen que es su mayor preocupación; sin embargo, el 60% de las mismas, declaran que no creen que el actual modelo de formación presencial, mucho mas común todavía que los modelos de e-learning, sea la forma más eficaz ni de gestionarla, ni de retener el conocimiento en la compañía en estos nuevos tiempos.

Otro punto a tener en cuenta es que, mientras que el ROI en los procesos de formación basados en las nuevas tecnologías es mucho más alto que en el modelo tradicional, el coste de desarrollo de dichas tecnologías sigue suponiendo un freno a muchas empresas. Entonces, ¿cómo solucionar la dicotomía existente entre coste y beneficio? Y aún más, ¿cómo hacer que una vez realizada dicha formación el conocimiento quede dentro de la compañía?

Una posibilidad que cada día está tomando más fuerza es la utilización de plataformas de contenido que nos permitan tanto la creación de documentación, como la formación y la evaluación de la misma en toda la empresa. Estas plataformas lo que habilitan a la empresa es el crear un conjunto de documentación y demostraciones, totalmente exportables, que faciliten la gestión de la formación interna, y que permitan que el conocimiento permanezca en la empresa aunque el personal deje la compañía. ¿Cómo? Dichos conjuntos de documentación sólo necesitan crearse una vez y se puede, desde crear documentación por procesos específicos (¿cómo introducir una factura en JD Edwards?) hasta procesos más complejos y completos (Gestión del almacén).

Una de estas plataformas es: User Productivity Kit (UPK) de Oracle.

UPK es una plataforma de contenido sincronizada para la creación de documentación, la formación y la asistencia de rendimiento de toda la empresa. Generalmente, su uso se limita a un equipo de autores de contenido, que son los que conocen a fondo los procesos a tratar. Los usuarios finales pueden disponer de dicho contenido bien a través de un  reproductor (Player) o de un documento con todos los pasos a seguir.

UPK le permitirá crear y publicar contenido fácilmente. Este contenido incluye simulaciones, soporte de aplicación y documentación interactiva. De esta forma, los usuarios obtienen un conocimiento completo de la funcionalidad del software, además de comprender los conceptos, al aprender a utilizar un programa en un entorno simulado y mientras trabajan con sus propios datos en un entorno real.

Los modos de utilización del UPK son los siguientes:

• El modo See It! permite a un usuario aprender mientras observa una demostración animada de los pasos de una tarea que se realiza en un entorno simulado. Todas las actividades necesarias como, por ejemplo, el movimiento del ratón y la introducción de datos, se realizan automáticamente.

• El modo Try It! permite a un usuario aprender de forma interactiva en un entorno simulado. El usuario sólo tiene que hacer clic con el ratón o pulsar las teclas para completar la tarea.

• El modo Know It? es un modo de reproducción tipo evaluación en el que los usuarios deben completar una tarea concreta. Los usuarios no recibirán instrucciones paso a paso para completar una tarea. En su lugar, deberán completar los pasos por sí mismos en un entorno simulado y recibirán la puntuación en relación a la precisión con que los realicen.

• El modo Do It! Mode permite a un usuario aprender de forma interactiva con datos reales. El usuario visualiza una pequeña pantalla en la parte superior de la aplicación real en la que se muestra cada paso de una tarea concreta. A medida que el usuario realiza cada paso, puede hacer clic en un botón o utilizar una combinación de teclas de acceso directo para visualizar el siguiente paso del proceso. La ventana Do It! incluye un gráfico en miniatura de la pantalla con un texto resaltado que indica el área en la que debe tener lugar la acción

Como consecuencia el poder utilizar una herramienta como el UPK nos permite minimizar los costes de formación interna, ya que no se requiere la presencia de formadores. Además permite generar en un fichero comprimido la documentación de la formación necesaria para un puesto determinado y que ésta, se encuentre en el PC del alumno de forma local lo que permita su visualización en caso de duda.  Asimismo, el uso de una herramienta como ésta nos permite la estandarización de la formación y lo más importante: que el know-how resida en la compañía.

Si quieres ver una demostración de cómo funciona el UPK, pincha en el siguiente enlace. Si te pregunta si deseas cerrar la ventana, selecciona ‘NO’. A continuación pincha en el logo que te aparecerá en el centro de la ventana y se iniciará la demostración con la que podrás interactuar en los diferentes modos de utilizacíón, tal y como te he explicado en este artículo.

                                                               Demostración de la solución User Productivity Kit (UPK)

 Esperamos tus comentarios sobre esta solución.

Mario Garcimartín

El título de este capítulo puede inducir a error. Que nadie piense que estoy preparando las normas de comportamiento de una ONG. Lo que pretendo, modestamente, es establecer pautas de conducta.

Los otros no son sólo los próximos: hijos y pareja, padres y hermanos, amigos y vecinos; pueden ser también rivales y competidores, colegas y jefes, clientes y proveedores. Estamos obligados a tratar con todos, y probablemente nuestra educación nos permita hacerlo dentro de estilos generalmente aceptados.

Pienso, que no hay soluciones exactas para mejorar nuestras relaciones personales, pero hay una premisa: “es imprescindible que nos preocupemos de los demás”.  La famosa frase “hola, que tal estás”, encubre siempre una obligatoria dosis de hipocresía, que tarde o temprano se delata a si misma. No debemos renunciar a las cortesías habituales, pero debemos exigirnos diariamente un mínimo de sinceridad cuando sentimos las desgracias de otros o nos alegramos del éxito ajeno. Hay que tomar conciencia de que nuestras felicitaciones y nuestros pésames no sean meramente protocolarios.

Una de las habilidades mas difíciles de encontrar (al menos para mí) es la “Empatía”.  Igual que otras muchas, forma parte de la propia personalidad. Se es o no empático de la misma forma que se es moreno o rubio, pero con voluntad puede y debe adquirirse y perfeccionarse. La empatía es la capacidad de ver los asuntos como los ve el otro, desde su posición y circunstancia. No es preciso asumir su punto de vista, pero si comprender por qué piensa así. En cualquier negociación, las personas empáticas tienen ventaja, han recorrido un largo camino antes de que la parte contraria haya terminado de defender sus posiciones.

Para perfeccionar nuestra empatía, (sea ésta mucha o poca)  debemos interesarnos por la persona que tenemos enfrente; conocer sus aficiones, entender sus necesidades y objetivos. Pongámonos realmente en el lugar del otro o intentémoslo, al menos, con “sinceridad”. Pienso, que con este gesto generoso, estaremos ocupando su terreno, jugando sus cartas, viendo el problema desde más ángulos. En definitiva, siendo más eficientes.

Quiero aquí hacer una observación, la empatía no debe confundirse con la “identificación”  ni, menos aún, con la “imitación”. Hay quien por hacerse perdonar el hecho de ser diferente, adopta sin darse cuenta gestos y entonaciones del interlocutor. De hecho, un par de veces durante mi vida profesional, he visto la metamorfosis realizada en la persona; adoptando las mismas posturas, voces y gestos. El empático no pierde su personalidad, simplemente entiende a la persona y valora el porqué de sus reacciones para poderle contestar adecuadamente.

Al interesarnos por los demás estamos procurando nuestro propio beneficio. No es altruismo lo que hace progresar al mundo; gracias al deseo de obtener un beneficio por parte del panadero y del lechero, gracias a su egoísmo, podemos contar todas las mañanas con leche y pan, a tiempo y en un lugar accesible.

En cualquier caso, cuidado con pretender ganarlo todo en la transacción, porque podemos quedarnos sin interlocutor. El “da y recibirás”, debería ser una norma permanente de las personas. Hay que dar algo a cambio, en toda transacción, y no solamente en las negociaciones mercantiles o políticas. La norma del “da y recibirás” es aplicable siempre, y muy especialmente cuando se trata de relaciones personales.

Es difícil obtener la distancia existente entre nuestras aspiraciones y lo que realmente podemos conseguir, y aún más entre lo que querríamos alcanzar y lo que, en justicia, debería alcanzar la parte contraria. Entran aquí en conflicto nuestra ambición y nuestra capacidad de empatía. Yo pienso que una buena táctica sería: “Conceder primero, plantarse, y esperar la contrapartida para dar una nueva concesión, o replegarme a una posición previa hasta que el contrario abandone la posición de fuerza”.

Al hablar anteriormente de la empatía, se me ha olvidado comentar algo que considero muy importante: “La ética profesional”. Interpretar las emociones ajenas sin ninguna referencia moral, sólo puede serle útil a un tahúr durante una partida de póquer.

Cuando al ver a una persona en una situación ridícula sentimos la desagradable sensación de la tan famosa  y tan malinterpretada “vergüenza ajena”, sólo estamos evidenciando que sentimos por el otro, que su dolor también es el nuestro. Nada de esto sería posible si no sintiéramos afecto por nuestros semejantes. Por consiguiente, pienso que es muy importante utilizar la ética desde la misma empatía.

Y ya para finalizar, me gustaría dar un último repaso a uno de los aspectos que conformarían (bajo mi punto de vista) el “todo para el interés hacia los otros”, junto con la empatía y la ética: la verdad. ¡ Señores !, “la mentira no paga”. Me viene a la mente la educación que recibían los jóvenes persas; eran ejercitados en tres artes: montar a caballo, disparar con el arco y ….. no mentir. La mentira y la traición, siempre son acompañadas por el desprecio. Si las personas con las que trabajamos son de nuestro interés, “la mentira no tiene objeto”, ni siquiera para bromear. Puede que, debido a determinadas circunstancias, nos veamos obligados a ocultar la verdad, pero nunca, nunca debemos mentir. Desde luego, para mí, prefiero negarme a contestar. No seamos como los políticos: que cuando son entrevistados, “dicen brillantemente  lo que están dispuestos a decir, con absoluta independencia del contenido e intención de la pregunta”.

Saludos

Roberto Andrés

Evidentemente y atendiendo a estos puntos de partida casi todos, sobre todo los programadores, se podrán ver interesados o atraídos por ciertas características de estos métodos. En este artículo no se pretenden exponer las virtudes, pros o contras de estas metodologías ágiles, ni tampoco justificar o explicar los posibles problemas encontrados a lo largo de la implantación de proyectos pasados o futuros, sino simplemente realizar una recopilación de la existente literatura al respecto de estos métodos menos conocidos, a la vez que desde mi doble punto de vista como diseñador y desarrollador, exponer alternativas a los métodos que se llevan usando desde hace ya más de 30 años. No nos engañemos, Ken Beck, uno de sus creadores y principales valedores lo puso en marcha para rescatar el proyecto C3 de Chrysler a finales de los 90 y este proyecto tuvo que ser finalmente cancelado, luego podemos casi asegurar que no se trata de la panacea que arregle todos nuestros problemas, pero evidentemente encontraremos algunos puntos que nos serán fácilmente identificables como útiles para su aplicación en nuestros proyectos.

Como ya comentábamos, estos métodos suponen principalmente un choque entre dos estilos; el diseño evolutivo/adaptativo y el diseño planeado/predictivo.

Esencialmente, evolutivo significa que el diseño del sistema crece conforme se implanta el sistema; el diseño es parte del proceso de programación y conforme el programa evoluciona el diseño cambia. Habitualmente esto se convertirá en un desastre; el diseño en estos casos se reduce a una serie de decisiones puntuales tomadas sobre la marcha que irán inevitablemente complicando la posibilidad de mantenimiento del código a medio y largo plazo. Conforme el diseño se deteriora, igualmente se deteriora la capacidad de cambio y con él se facilita la generación exponencial de errores que cada vez serán más difíciles (y costosos) de eliminar. Estas son principalmente las complicaciones del típico “codifica y corrige” al que en gran parte nos hemos acostumbrado los programadores. Los teóricos de la metodología denominan a este fenómeno como la Entropía del Software.

El diseño planeado al contrario, se basa en prácticas extraídas de la ingeniería. Si queremos construir por ejemplo un edificio, no podemos empezar a poner ladrillos a lo loco sino que realizaremos ciertos estudios, esquemas, códigos y diagramas utilizando diversas técnicas matemáticas y de estructuras, tras lo cual podremos abordar su construcción o encargársela a otra empresa para que lo construya.

En software todo debería funcionar de manera similar. Los diseñadores no pensamos en programar ya que solo lo estamos planeando, se piensa en los problemas con anticipación, y por ello utilizamos diferentes técnicas que dejan de lado los detalles de programación de bajo nivel para dedicarnos a un nivel más abstracto. Al igual que en el edificio estamos convencidos de poder diseñar un software a imagen y semejanza de una lógica de negocio y que podemos pasarlo después a los programadores o bien a otra compañía para que construya dicho software.

Así llevamos ya cerca de 30 años y aunque a priori parece mejor que el sistema de codificar y corregir, nuestra experiencia sabe que esto no siempre es así.

Sabemos que es totalmente imposible en un sistema de una complejidad media el haber pensado en todos los problemas que se necesitan tratar al programar y que aparecerán inevitablemente problemas que pondrán al diseño en entredicho, además no contaremos ni con un plazo suficientemente amplio para la realización del proyecto a la vez que tendremos unos márgenes comerciales más ajustados.

Normalmente en estos casos se realizará un cambio rápido en el diseño por la presión de tiempo a la que casi seguro estaremos sometidos, provocando con esto de nuevo el crecimiento de nuestra famosa Entropía, siendo en ocasiones obligados a lanzar el software incluso con un conjunto en teoría conocido de defectos y deficiencias. El software es lanzado con esos defectos conocidos porque el valor del software en un determinado nivel de calidad (teóricamente) compensa el impacto de los defectos y deficiencias conocidas.

Roberto Andrés

Las Metodologías de Diseño fueron creadas para imponer un proceso disciplinado en el de por sí caótico proceso de desarrollo de software con el fin de hacerlo más predecible y eficiente. De esta manera, a lo largo de los años se han venido diseñando métodos de diseño, en donde los últimos exponentes han sido UML, RUP, Métrica, etc,… 

Aún así y como ya sabemos, todas estas metodologías conllevan una ingente cantidad de pasos, etapas, documentación y ‘burocracia’ asociada, que retrasan considerablemente el proceso de desarrollo, siendo en ocasiones muy difícil de seguir escrupulosamente todos estos pasos consiguiendo en ocasiones su abandono o su seguimiento con laxitud a lo largo del proceso, siendo este mayor cuanto más crítico debería de ser su seguimiento. 

En este punto surgen los Métodos Ágiles, dentro de los cuales encontramos entre otros XP (Xtremme Programming) , SCRUM, Agile Unified Process y FDD (Feature Driven Development), intentando ser un punto medio entre las metodologías altamente burocratizadas y la ausencia total de método que nos podría abocar a un caos absoluto. Estas metodologías suponen grandes cambios  en los métodos habituales siendo alguno de los más controvertidos el rechazo a un esfuerzo significativo en el diseño previo, en favor de un estilo más evolutivo en el que sin disminuir la calidad si reduzcamos la documentación, pasos, procesos y tiempo de desarrollo necesarios para la consecución del proyecto. 

En próximas entregas analizaremos estas metodologías, como comienzo para su posible evaluación y su integración total o parcial dentro de la gestión de proyectos.

Emilio Mayoral

Mucha es la documentación que en un proyecto es necesaria. A continuación os trasmito mi opinión personal sobre uno de estos documentos que se está quedando en desuso y que me parece es de gran importancia en el ciclo de desarrollo del software. Os hablo del plan de pruebas.

La finalidad del plan de pruebas es básicamente, la detección de errores a todos los niveles. Este documento debe de empezar a generarse al inicio del proyecto e irse incrementando durante el desarrollo del mismo, ya que es vital que estos errores se detecten cuanto antes para que el coste de la corrección de los mismos sea el menor posible.

¿Por qué está desapareciendo?

Todos nos hemos dado cuenta que en la actualidad, a la velocidad en la que nos vemos inmersos a la hora de desarrollar nuestro trabajo de consultoría, la documentación ha pasado al plano de lo estrictamente necesario. Un análisis funcional, un orgánico (que por funcionalidad se ha embebido por el anterior) y un cuaderno de carga por cada módulo independiente que desarrollamos, es lo que más nos estamos encontrando. Pero, ¿y un plan de pruebas?, qué ha pasado, ¿por qué ha dejado de utilizarse?

Realmente, hay que reconocer, que es un documento muy laborioso que implica la participación:

• De los funcionales, para definir los resultados los distintos módulos del proyecto y la interconexión entre ellos.
• De los técnicos, que deben de definir el resultado de cada uno de los programas que desarrollan.
• De los jefes de proyecto, que definirán los recursos, calendarios, hitos, planes de contingencia,etc.
• Usuarios, que deben dar el visto bueno a los resultados obtenidos.

 Y que además, el plan de pruebas, es un documento que estará vivo hasta el final del proyecto, por no olvidar que puede llegar a niveles de ingeniería, a mediciones de rendimiento, pruebas de estrés, de estabilidad, etc.

Tenemos que tener en cuenta, que el plan pruebas no se puede considerar un simple documento, si no que sirve de estabilizador del proyecto, al ser el nexo entre la toma de requerimientos y el producto final y que obliga a la participación de todos los miembros del equipo de proyecto, incluido por supuesto, el usuario final.

Este último punto es muy importante ya que supone la participación activa y comprometida del usuario final y obliga al cliente a aceptar, o mejor dicho, participar, en las pruebas realizadas al producto desarrollado. Esto puede ser algo tedioso ya que dependemos de la aptitud y compromiso de usuarios que en múltiples ocasiones nos pondrán pegas y provocarán mayor esfuerzo del que esperábamos, pero nos asegura que a la larga nos dará la tranquilidad necesaria para ir avanzado a siguientes hitos del proyecto sin dejar casos pendientes que nos vayan retrasando cada vez que debamos retomarlos.

Para resumir sólo identificar algunos (no todos), de los beneficios de la realización de un buen plan de pruebas:

• División de programas en módulos analizables individualmente.
• Implicación de todo el equipo en el proyecto
• Detección de errores a tiempo.
• Detección de problemáticas no tenidas en cuenta en el análisis inicial.
• Integración del usuario mediante compromisos de aceptación. 

Un saludo