Juan Sáenz de Tejada

El oficio de bodeguero ha cambiado mucho con los años, ha pasado de ser un personaje al que se le atribuían toda clase de fechorías  (aguar los caldos, echar zapatos para dar mas cuerpo…)a ser un gestor eficaz y eficiente con un solo objetivo: la calidad del vino. Está búsqueda de la excelencia, ha hecho que muchas bodegas de todos los tamaños iniciaran una mejora continua del proceso productivo, cambiando los depósitos por otros de acero inoxidable, nuevas barricas, es decir modernizando el proceso vitivinícola por otro mas eficaz que producen caldos de mayor estabilidad y calidad, homogeneizando la calidad del vino a través de las distintas campañas. Entonces, ¿todo está hecho? ¿Ya han alcanzado las bodegas el grado de modernización necesario? La respuesta es no. Así como se ha hecho mucho en el proceso productivo, es decir, en cómo hacer el vino de una manera mas eficaz, los procesos referentes a tecnologías de la información, que sustituyen a procesos con una gran carga de trabajo administrativo,han quedado para una segunda fase, y ésta ya ha llegado.

¿Cómo saber si una campaña ha tenido una relación coste beneficio adecuada, si no tenemos herramientas para reflejar los trabajos que se han hecho en cada una de las fincas, que parte de mano de obra, uso de maquinaria o de gastos imprevistas hemos tenido por cada finca? Como trasladar estos costes al precio del vino? ¿Como medir de manera automática las entregas de  uva, por finca o agricultor? ¿Cómo facturarles automáticamente por hecto grado o por kilo? ¿Puedo tener distintas formas de facturación para cada entrega?¿Cómo controlar de manera gráfica distintas variables por cada una de las fincas? O ¿cómo tener de manera automática y constantemente actualizada la trazabilidad del vino de la botella a la viña? o ¿como controlar el coste real de cada campaña, incluyendo procesos de embotellado y etiquetado?

Pues todos estos procesos que suponen una gran cantidad de trabajo administrativo pueden ser fácilmente controlados, y estudiados con el sistema ERP de Solmicro eXpertis Bodegas en el que de una forma fácil y barata podemos controlar todas las operaciones que pueden hacer que nuestra bodega sea mas efectiva, desde los trabajos de campo, controlando los costes directos que suponen, hasta el control de la etiquetas en el tren de etiquetado, sin olvidar todos los procesos y operaciones que necesitamos controlar para tener un control efectivo de la trazabilidad del vino de la viña a la botella.

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

La clave de la reunión fue conocer de primera mano las novedades que ofrece la nueva versión 5.0 de su software de gestión empresarial Solmicro-eXpertis ERP, así como nuevas capacidades y módulos que impactan positivamente en la gestión del negocio de los clientes: CRM, Cuadros de mando, Sistema de Mensajería y Alarmas, TPV o Factura Electrónica…

Leer más: http://www.solmicro.com/fabricantes-software/noticias-informacion-erp/notas_de_prensa/version-erp-expertis-nueva

A partir del 1 de julio, la subida del IVA se aplicará en toda España, pero los programas de las empresas, hechos a medida, seguirán facturando con el porcentaje anterior, por lo que podrían empezar a funcionar mal.

Leer más: http://www.elmundo.es/mundodinero/2010/06/01/economia/1275389772.html

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.

Angel F. Viartola

EnterpriseOne cuenta con unas cuantas herramientas y utilidades que son muy poco conocidas, y menos utilizadas, que facilitan muchas tareas de desarrollo y permiten simplificar procesos.

Por ejemplo, frente a la tradicional forma de gestionar ficheros de texto (abro fichero, leo líneas de una en una, cierro fichero) disponemos de la posibilidad de invocar a una función que se encarga de abrir el fichero, leerlo, subirlo a una tabla línea a línea, asignándole un número de lote, una descripción, incluso un código de informe y versión para que después pueda ser gestionado leyendo la tabla. Y todo esto únicamente invocando a una función de negocios. El leer un fichero de texto en una tabla permite utilizar cursores para leerlo en dos pasadas, o recorrerlo como queramos conveniente.

Disponemos de API’s que nos permiten leer las opciones de proceso de otras aplicaciones e informes, de manera que no necesitamos agregar opciones de proceso a una aplicación o hacer extrañas llamadas de unas a otras, podemos leer las que queramos desde donde queramos, añadir aplicaciones “dummy” que sólo se usen para asociarles más opciones de proceso, leer las de unas aplicaciones desde otras…

Tampoco solemos utilizar las directivas del preprocesador, opciones de compilación que nos permiten personalizar las funciones de negocio para que se compilen adecuadamente en cada una de las posibles máquinas, de forma que podamos tener código específico para Unix/Linux, Windows o AS/400 dentro de la misma función.

Uso de ftp para la gestión de objetos de medios, posibilidad de invocar directamente a los distintos “mafflets” pasándoles parámetros, inclusión de gráficos de barras o sectores en pantallas y otras muchas posibilidades a nuestra disposición para mejorar el rendimiento, la programación o la visualización de nuestras aplicaciones.

Os iremos contando más cosas.

Saludos.

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.