DEFINICION ERP

ERP (siglas en ingls de Enterprise Resource Planning) conocida en nuestro idioma como Planificacin de Recursos Empresariales. Hoy en da nos encontramos en una poca en la que la informacin se genera cada segundo de forma instantnea en todas las organizaciones y en cada uno de sus niveles, en el mbito empresarial, tener a la mano la informacin necesaria pude significar una ganancia o una prdida monetaria, a travs de las ltimas dcadas, han aparecido y evolucionado los sistemas de planeacin de los recursos empresariales para ayudar en este sector, mejor conocidos como ERP, son un tipo de software que permite a las empresas controlar la informacin que se genera en cada departamento y cada nivel de la misma. El fin de los ERP es el de INTEGRAR los departamentos, donde antes haba un sistema de informacin especializado para cada rgano de la empresa, los ERP son capaces de generar una base de datos limpia, donde se gestione la informacin en tiempo real y se pueda obtener los datos requeridos en el momento que se desee. Cmo Funciona un ERP? Como cualquier software, funciona en base a una plataforma de programacin, seguida por la gestin de un sin fin de bases de datos correspondientes a los distintos departamentos que se deseen integrar. Los sistemas ERP se organizan por medio de MDULOS, los cuales se conectan a distintas bases de datos, segn lo que se requiera para cada departamento, existen 2 tipos de ERP, los de propietario y los de cdigo abierto, los de propietario son hechos por empresas con fines de lucro que venden sus software y los implementan a las empresas que lo soliciten a un elevado costo, para poder utilizarlos se necesita obtener una licencia mas el costo de la implementacin del software en la empresa. Al contrario de los ERP de cdigo abierto, estos son hechos por comunidades de programadores que sin fin de lucro, distribuyen sus ERP sin costo alguno, aunque esto no signifique que sea del todo gratuito, ya que la implementacin genera un costo en la empresa y es necesario de una persona capacitada que lo realice (conocidos como partners). El trabajo ms duro de un ERP es el desarrollo del mismo, aunque existan los mismos ERPs para diferentes empresas, no signifique que estos realicen las mismas funciones, esto ocurre porque cada empresa es diferente y por lo tanto necesita de un desarrollo

personalizado de los distintos mdulos que mas utilice la empresa. El segundo paso del ERP es la integracin del mismo dentro de la empresa, son realmente muy pocas las empresas que logran integrar estos sistemas desde el inicio de la misma, es por esto que la implementacin dura ms tiempo del esperado, pero el verdadero xito del ERP radica en lo siguiente, una vez que el sistema ha sido correctamente implementado, es mucho ms fcil el desarrollo de nuevos mdulos, departamentos y sistemas como lo es el caso de empresas donde cambien constantemente sus productos, zonas de venta, insumos etc..

HISTORIA Los antecedentes de los ERP datan de la Segunda Guerra Mundial, cuando el gobierno estadounidense emple programas especializados que se ejecutaban en las enormes y complejas computadoras recin surgidas en el principio de la dcada de los aos 40 para controlar la logstica u organizacin de sus unidades en acciones blicas.

Estas soluciones tecnolgicas, conocidas como los primeros sistemas para la planeacin de requerimiento Requirements de materiales Systems (Material o MRP

Planning

Systems), son el antecedente histrico ms remoto de los actuales ERP.

AOS 50 Los sistemas MRP brincaron las trincheras del ejrcito para hallar cabida en los sectores productivos en especial de los Estados Unidos de Amrica. Las compaas que los adoptaron se dieron cuenta de que estos sistemas les permitan llevar un control de diversas actividades como control de inventario, facturacin, y pago y administracin de nmina.

De

manera

paralela,

la

evolucin

de

las

computadoras favoreci el crecimiento de estos sistemas en cuanto al nmero de empresas que optaban por ellos. Claro que esas computadoras eran muy rudimentarias pero contaban con la capacidad de almacenamiento y recuperacin de datos que facilitaban procesar transacciones, es decir, manejar informacin y canalizarla de manera apropiada a aquellas reas que, al integrarla, podan ejecutar acciones mucho ms rpidas.

AOS 60 Y 70

Los sistemas MRP evolucionaron para ayudar a las empresas a reducir los niveles de inventario de los materiales que usaban, esto porque, al planear sus requerimientos de insumos con base en lo que realmente les demandaban, los costos se reducan, ya que se compraba slo lo necesario. Si hacemos una

comparacin con la preparacin de un atleta, podemos decir que era como administrarle la dieta al competidor, evitando desperdiciar en la comida que no le hiciera falta

AOS 80 Estas soluciones tecnolgicas pasaron a usar otras siglas: MRP II o planeacin de los recursos de manufactura (Manufacturing Resource Planning). Su alcance fue distinto: permitan atender factores relacionados con la planeacin de las capacidades de manufactura; un MRP II, a diferencia de los sistemas previos, reconoca que las empresas padecan interrupciones en la operacin, cambios sbitos y limitaciones en recursos que iban ms all de la disponibilidad de materiales. Retomando nuestra analoga del deportista, un MRP II era

como un entrenador que reconoca, por fin, que su atleta poda enfermarse o fallar en su rendimiento.

AOS 90 En los aos 90, ya haba dos posiciones en el escenario de soluciones tecnolgicas para empresas: por un lado los MRP y por otro los MRP II. Pero el mundo haba cambiado y estas soluciones nacidas en los ambientes de manufactura ya eran

insuficientes para un mercado donde haba organizaciones de todo tipo: de servicios, financieras, comerciales, entre otras, que tambin necesitaban una solucin para controlar sus procesos y, en consecuencia, ser ms competitivas. Pero fue en los 90 cuando el trmino ERP (Enterprise Resource Planning) fue asignado a estos sistemas. Logrando que los ERP generarn un mejor grado de integracin horizontal de las empresas ahora. Los sistemas ERP marcan un punto significante en el desarrollo de los sistemas.

ACTUALIDAD Actualmente la mayora de los negocios han cambiado su forma de llevar su administracin, necesitan llevar todos sus departamentos

organizados y relacionados, por eso se han hecho presente los sistemas ERP y CRM.

Estos programas permiten tener un control de todas las transacciones que se hacen dentro de la empresa, sobre todo la contabilidad ya que te permite tener un catlogo de todas las operaciones que se realizan en la empresa, sean procesos administrativos,

productivos o logsticos. Aqu vemos un xito de

estos programas. Antes el llevar la contabilidad de una empresa era complejo, pero con estos sistemas que surgieron en los 90s se ha podido llevar la contabilidad de una forma ms fcil.

Para aumentar la capacidad de una empresa, invertir en ms mquinas no es la nica opcin, ya que con sistemas ERP se puede hacer ms con lo mismo al aplicar inteligencia de negocios.

IMPLEMENTACION

Implementar un Sistema ERP es una decisin muy difcil de tomar para las empresas que lo realizarn por primera vez. Antes de decidir si implementan o no un Sistema ERP, la persona encargada de realizar esto tiene la obligacin de valorar los siguientes aspectos:

a.

Organizar el proyecto:

Los sistemas ERP se podran catalogar como sistemas selectos que solo pueden ser implementados por algunas empresas, ya que los costos que stos representan son muy altos. Es decir, cuando las empresas cuentan con el dinero, los equipos, la infraestructura y la disposicin de personal para la implementacin de este tipo de sistema, se puede decir que se debe dar el primer paso, organizar como es que va a funcionar y desarrollar el proyecto que dar una nueva funcionalidad y visin de los recursos y procesos de la organizacin a cada rea de la empresa.

b.

Definir las medidas de desempeo:

Cuando el proyecto ya se ha planteado, se debe definir las actividades que se deben realizar para poder llevarlo a cabo. Se debe tener en cuenta hasta el ms mnimo detalle para la implementacin del sistema ERP.

c.

Crear un plan inicial detallado del proyecto:

Como todo proyecto, la implementacin de un Sistema ERP implica una adecuada distribucin de tiempo, empleados, funciones y recursos; por lo cual es de vital importancia que se

planifiquen cada una de las actividades que se van a llevar a cabo, que se construya una bitcora que gue cada uno de los pasos a seguir.

d.

Capacitar al equipo para el proyecto:

Como los Sistemas ERP son nuevos, se debe de hacer una capacitacin en la cual se incluyan cada uno de los empleados que posteriormente ante ste se van a desenvolver. Esta implantacin se torna en una situacin nueva que revoluciona el quehacer diario del talento humano. Para la implementacin de sistemas tan avanzados como ste, muchas veces se debe ensear a algunos empleados hasta como prender un computador, ya que en algunas empresas y sobre todo, en algunos puestos de trabajo especfico, este tipo de tareas no son muy conocidas por las personas.

e.

Revisar la integridad de la base de datos:

La integridad de la base de datos, constituye uno de los pasos ms importantes en la implementacin de cualquier sistema de informacin, pero en especial de los sistemas ERP. La base de datos se convierte en el eje central del proceso, es la encargada de almacenar, distribuir y reportar la informacin que se va a manejar en los distintos niveles de la organizacin.

f.

Instalar el nuevo hardware:

El hardware o parte dura del proceso es una de las mayores inversiones de la empresa. Se deben abolir la vieja tecnologa utilizada por la empresa, para instalar nuevos equipos que puedan dar soporte al desarrollo de este sistema.

g.

Instalar el nuevo Software (montar sala piloto):

El nuevo software a instalar, se convierte en una sala piloto o una sala de prueba, la cual ser utilizada en todo el proceso de instalacin del sistema. Se debe tener un continuo cuidado de cada uno de los pasos realizados, ya que el software es la medula espinal del sistema.

h.

Capacitar masa crtica:

La masa crtica se refiere al personal de la empresa. Se define como crtica ya que se refiere al personal que va a estar directamente relacionado con el nuevo sistema, es decir, el que va a estar en continuo contacto y el encargado de la manipulacin del mismo.

i.

Entrenamiento sala piloto:

Una vez instalada la sala piloto, se debe pasar a la utilizacin de la misma, por medio del entrenamiento que al personal se le dar en ella.

j.

Integracin de datos:

La integracin de datos consiste en la recopilacin de la informacin proveniente de diferentes fuentes o reas organizacionales, que hasta el momento no han sido organizados. Esto se convierte en la base del funcionamiento del sistema.

k.

Ejecucin:

Poner en marcha el Sistema ERP no es fcil, se debe pasar por todas las etapas anteriores teniendo en cuenta que el xito o fracaso en cualquiera de ellas puede limitar la ejecucin del sistema.

l.

Mejoramiento continuo:

Tener un registro del desarrollo del sistema, hacer una continua retroalimentacin de ste e implementar un mejoramiento continuo son las caractersticas de las compaas que han sido victoriosas en la implementacin de este tipo de sistemas.

VENTAJAS

La principal ventaja de los ERP es la gestin en tiempo real de la informacin, una ventaja que las empresas agradecen mucho por su fuerte interaccin con la logstica de informacin y productos, la cadena de abastecimiento, estadsticas financieras, y otras reas que utilizan informacin que cambia constantemente.

La correcta implementacin de los ERP repercute en el aumento de productividad de todos los departamentos, as como el mejor aprovechamiento del tiempo, donde antes se necesitaba tiempo para llevar un informe de un departamento a otro, ahora ese tiempo es utilizado en otras funciones.

Estandarizacin e Integracin de la informacin en una base de datos centralizada. Mayor control organizacional. Minimiza el tiempo de anlisis de la informacin. Optimizacin de los tiempos de produccin y entregas. Disminucin de costos. Se cuenta con informacin actualizada que permite la toma de decisiones. Evita duplicidad de informacin. Cuenta con mdulos configurables de acuerdo a cada rea de la empresa.

DESVENTAJAS

Aunque los sistemas ERP puedan generar un incremento de productividad, para muchas empresas es casi imposible pagar el costo de las licencias, implementacin y sobre todo del mantenimiento del mismo, ya que son sistemas dinmicos, de nada sirve tener el mismo sistema en una empresa que crece y cambia da a da.

Adems del costo, el tiempo que sugiere la implementacin es un problema para las empresas, este problema empieza por la rigidez que tienen los ERP, es difcil que una empresa en particular desarrolle su propio sistema, los ERP que son sistemas genricos, tienen que ser adaptados a las empresas desde su estructura principal.

El manejo del ERP tiene sus desventajas, se necesita instruir a los trabajadores de cada modulo que se vaya a asignar, la especializacin de los trabajadores genera un costo y tiempo que tiene que emplear la persona para hacer un cambio en su estructura operativa, lamentablemente la resistencia al cambio presenta un problema muy grande en este punto.

La implementacin puede requerir importantes cambios en la empresa y los procesos. Es tan complejo que muchas compaas no pueden ajustarse a l. Requiere de procesos actuales (en curso), por lo cual la implementacin puede nunca ser completada.

En el mercado los expertos en Sistemas ERP son limitados, por lo cual se pueden presentar problemas en la contratacin.

COMPARATIVA ERPs

ERPs

Compiere Fue creada en 1999 por Jorg Janke. Proyecto del top 10 en Sourceforge. En 2006 consigui capital con el objetivo de transformar el exitoso proyecto ERP en un negocio comercial de cdigo abierto exitoso y sostenible. 2007 modernizaron la ingeniera y el soporte de procesos. Se expandi para incluir las ediciones Professional, Enterprise y Cloud mientras la compaa continuaba manteniendo la versin de cdigo abierto como Community Edition. 1999

Openbravo Es un software de cdigo abierto. Desarrollado por la empresa Openbravo. Se trata de una empresa espaola fundada en el ao 2001 en Pamplona En la actualidad dispone de ms de 100 empleados, con oficinas en Pamplona y Barcelona, as como una red de Partners en cerca de 50 pases.

Openerp 2004 naci TinyERP. Fabien Pinckaers. Creacin compaa belga Tiny Sprl. 2007. Apertura repositorio SVN 2008. Migracin plataforma Launchpad-Bazaar 2008. TinyERP OpenERP 2009. Mejoras desarrollo colaborativo Evolucin (# de mdulos):

Abanq La empresa infoSiAL es una empresa espaola. Principal desarrolladora y administradora del proyecto AbanQ. Proyecto reconocido por la OSDN (Open Software Development Network) Alojado en Sourceforge.net

Oasis ERP Naci como respuesta a la necesidad de Software Libre. Para la gestin empresarial en el entorno de las PYMES de Castilla la Mancha (Espaa). Desarrollo han participado varias empresas agrupadas bajo 'DESERTIC' Tras 3 aos de desarrollo, el producto resultante fue un nuevo ERP.

Resea ERP

Ao de desarrollo

2001 (2006 liberaliza el cdigo)

2008

2007 (a partir de facturalux)

2009

ERPs

Compiere

Openbravo

Openerp

Abanq

Oasis ERP

Sitio web

www.compiere.com

www.openbravo.com

www.openerp.com

www.abanqg2.com www.abanq.org Gestin de procesos: permite gestionar todos los procesos bsicos de la empresa. Planificador de produccin: que permite a las empresas una reduccin costes significativa. Gestin comercial: permite a las empresas aumentar la eficiencia de su esfuerzo comercial, es decir, aumentar las ventas. Servicios: lleva integrados los mdulos caractersticos que permiten gestionar sus necesidades especficas.

www.oasis-clm.es

Funcionalidades

Implementacin rpida Verdadera integracin Errores sin consecuencias Un programa completo y de gran alcance Mercado internacional Interfaz inteligente de Usuario

Fcil: La interfaz de usuario en entorno web es intuitiva y fcil de descubrir. Potente: el diseo multi-tabla conjuntamente con los registros editables satisfacen a los usuarios avanzados ms exigentes Integrado: el modelo de datos completamente integrado con flujos de proceso eficientes facilita la colaboracin y gestiona las operaciones de principio a fin

Gestin de documentos, conectores con otras aplicaciones, permite trabajar remotamente mediante una interfaz web o aplicacin de escritorio multiplataforma (Windows, Linux y Mac) y incluye un entorno modular de programacin/adapta cin rpida de aplicaciones (OpenObject). Se basa en tecnologa Python/XML trabajando sobre una base de datos PostgreSQL.

Aplicacin de escritorio desarrollada totalmente con herramientas de Software Libre. Se puede instalar en un Servidor o en un puesto local. Es multiusuario, multiempresa, multisucursal, multimarca y multialmacn. Es altamente parametrizable y extremadamente flexible. Es modular

ERPs

Compiere 2 capas cliente/servidor previsin 3 capas.

Openbravo

Openerp 2 capas cliente/servidor MVC(3 capas)

Abanq

Oasis ERP

Arquitectura

MVC (3 capas)

A3d

3 capas

Lenguaje de programacin

JAVA

JDK

Python, PyGTK PostgreSQL

C++, Javascript PostgreSQL, MySQL GPL, GNU General Public License Version 2

PHP-GTK2

Base de datos

ORACLE

PostgreSQL y Oracle GPL (General Public License) OPL (OpenERP Public License)

PostgreSQL

Tipos de licencia

MPL,CPL

OBPL

GNU/GPL

CONTROL DE VERSIONES DEFINICION Un sistema de control de versiones es el encargado de la gestin de los diversos cambios que se realizan sobre los elementos dentro el desarrollo de un producto software. Los sistemas de control de versiones, en la actualidad se han convertido en un elemento indispensable en el proceso de desarrollo de un producto software; de igual forma se convierten en un aliado importante de la ingeniera de software en la tarea de conseguir como resultado un producto de software de calidad. Los sistemas de control de versiones desde sus inicios fueron utilizados principalmente en la industria informtica, pero hoy en da estos sistemas son utilizados tanto por industrias como por desarrolladores individuales, considerando que estos ltimos le dieron ms dinamismo a su desarrollo y evolucin. Los sistemas de control de versiones se constituyen en un buen complemento a los sistemas de backups.n CARACTERISTICAS GENERALES Gestionar el almacenamiento de cada uno de los elementos del proyecto. Llevar un historial de los cambios en cada elemento del proyecto y anota el autor de los cambios. Cada uno de los cambios se denomina revision. Posibilidad de aadir, borrar, mover o editar los elementos. Capacidad de gestionar ramas de desarrollo paralelas a la principal. Gestin de conflictos, en el caso de que ms de un usuario cambie un elemento del proyecto. Generacin de informes de estado, donde se muestren las diferencias entre distintas revisiones. TERMINOLOGIA La terminologa empleada puede variar de sistema a sistema, pero a continuacin se describen algunos trminos de uso comn.

 Repositorio: Es el lugar en el que se almacenan los datos actualizados e histricos, a menudo un servidor(proceso centralizado), el PC de los desarrolladores (proceso distribuido) Mdulo: Conjunto de directorios y/o archivos dentro del repositorio que pertenecen a un proyecto comn. Rtulo: Identificador asignado a un mdulo o fichero, asignado en un momento determinado, orientado a una bsqueda posterior. Revisin: Una revisin es una versin determinada de un archivo. Lnea base: Una revisin aprobada de un fichero, a partir del cual se pueden realizar cambios subsiguientes. Injertar rama o branch: Un mdulo puede ser branched o bifurcado en un momento dado, de forma que, en adelante, dos copias de esos ficheros puedan ser desarrolladas a diferentes velocidades o de diferentes formas, de modo independiente. Check-out: Permite crear una copia de trabajo local desde el repositorio. Se puede especificar una revisin especfica, por defecto se suele obtener la ltima. Commit o check-in: Los cambios realizados localmente son escritos o integrados sobre el repositorio. Conflicto: Un conflicto ocurre cuando el sistema es incapaz de fusionar los cambios, algunas veces precisa intervencin manual. Cambio: Un cambio representa una modificacin especfica a un fichero bajo control de versiones. Lista de cambios: Son listas que identifican una serie de cambios a realizarse en un solo commit. til al momento de revisar un cambio a partir de un identificador. Exportacin: Similar a un check-out, crea un rbol de directorios limpio sin los metadatos de control de versiones presentes en la copia de trabajo. Se utiliza a menudo de forma previa a la publicacin de los contenidos. Importacin: Una importacin es la accin de copia un rbol de directorios local (que no es en ese momento una copia de trabajo) en el repositorio por primera vez.

 Integracin o fusin: Una integracin o fusin une dos conjuntos de cambios sobre un fichero o un conjunto de ficheros en una revisin unificada de dicho fichero o ficheros. Actualizacin: Integra los cambios que han sido hechos en el repositorio (por ejemplo por otras personas) en la copia de trabajo local. Copia de trabajo: La copia obtenida desde el repositorio en el rea de trabajo local, se la realiza en un momento del tiempo o revisin especfica. Congelar: Representa permitir los ltimos cambios (commits) para solucionar las fallas a resolver en una entrega (release) y suspender cualquier otro cambio antes de una liberacin, con el fin de obtener una versin consistente. TIPOS DE COLABORACION Para colaborar en un proyecto usando un sistema de control de versiones lo primero que hay que hacer es crearse una copia local obteniendo informacin del repositorio. A continuacin el usuario puede modificar la copia. Existen dos esquemas bsicos de funcionamiento para que los usuarios puedan ir aportando sus modificaciones: De forma exclusiva: En este esquema para poder realizar un cambio es necesario comunicar al repositorio el elemento que se desea modificar y el sistema se encargar de impedir que otro usuario pueda modificar dicho elemento. Una vez hecha la modificacin, sta se comparte con el resto de colaboradores. Si se ha terminado de modificar un elemento entonces se libera ese elemento para que otros lo puedan modificar. Este modo de funcionamiento es el que usa por ejemplo SourceSafe. Otros sistemas de control de versiones (Ejemplo subversion), aunque no obligan a usar este sistema, disponen de mecanismos que permiten implementarlo. De forma colaborativa: En este esquema cada usuario modifica la copia local y cuando el usuario decide compartir los cambios el sistema automticamente intenta combinar las diversas modificaciones. El principal problema es la posible aparicin de conflictos que deban ser solucionados manualmente o las posibles inconsistencias que surjan al modificar el mismo fichero por varias

personas no coordinadas. Adems, esta semntica no es apropiada para ficheros binarios. Los sistemas de control de versiones subversin o Git permiten implementar este modo de funcionamiento. TIPOS DE ALMACENAMIENTO Podemos clasificar los sistemas de control de versiones atendiendo a la arquitectura utilizada para el almacenamiento del cdigo: Centralizados: existe un repositorio centralizado de todo el cdigo, del cual es responsable un nico usuario (o conjunto de ellos). Se facilitan las tareas administrativas a cambio de reducir la potencia y flexibilidad, pues todas las decisiones fuertes (como crear una nueva rama) necesitan la aprobacin del responsable. Distribuidos: se aumenta la capacidad de decisin distribuida, caracterstica que dar mayor flexibilidad en el uso, pero en algunos casos puede dificultar la sincronizacin. USO DE RAMAS Las ramas, en un sistema de control de versiones, constituyen una potente herramienta que flexibiliza la forma en la que los colaboradores cooperan en el proyecto (Branching Workflows). Las ramas son slo una herramienta que es posible utilizar de distintas formas para conseguir distintos objetivos. Ramas de largo recorrido En algunos proyectos se tiene varias ramas siempre abiertas, que indican diversos grados de estabilidad del contenido. Por ejemplo es frecuente mantener en la rama 'master' nicamente lo que es totalmente estable. Luego se tienen otras ramas que revelan distintos grados de estabilidad. Por ejemplo podramos tener un rama 'beta' (versin beta) y otra 'alfa' (versin alfa), en las que se va trabajando. Cuando se alcanza cierto grado de estabilidad superior a la rama en la que se est entonces se realiza una fusin con rama de estabilidad superior.

Ramas puntuales Las ramas puntuales, tambin llamadas ramas de soporte, son ramas que se crean de forma puntual para realizar una funcionalidad muy concreta. Por ejemplo aadir una nueva caracterstica (se las llama ramas de nueva funcionalidad o directamente por su nombre en ingls topic branch feature branch) o corregir un fallo concreto (se las llama ramas para corregir error o directamente por su nombre en ingls hotfix branch). Este tipo de ramas permiten trabajar centrndonos exclusivamente en el desarrollo de una caracterstica concreta y cuando esta est concluida se fusiona con una de las ramas de largo recorrido (normalmente con la de ms bajo nivel de estabilidad, para que sea probada en ese entorno). La fusin slo se realiza cuando se est 'seguro' de que esa caracterstica est correctamente implementada, en lugar de fusionar en el orden que se van desarrollando las cosas. Esto permite por un lado tener un historial de las distintas versiones que se han tenido hasta conseguir la funcionalidad. Por otro lado permiten que el historial de las ramas de largo recorrido no sea 'ensuciados' con distintas modificaciones relativas a una funcionalidad concreta. El uso de este tipo de ramas permite ms flexibilidad a la hora de probar posibles soluciones. Slo se fusiona con ramas de largo recorrido una vez que estamos seguros de elegir la solucin mejor. Un tipo de ramas de este tipo que tienen un funcionamiento especial son las llamadas ramas de versin o ramas de release (release branch). Este tipo de ramas se crear para dar soporte a la preparacin de una nueva versin de produccin. Permiten tener bajo control el contenido de la versin y poder cierto mantenimiento sobre ella (aadirle pequeas mejoras y correccin de errores). Es frecuente y una buena prctica utilizar en el nombre de la rama un prefijo que indique el tipo de rama de la que se trata. Por ejemplo podra usar 'feature-' para ramas de nueva funcionalidad, 'hotfix-' para ramas que arreglan errores, y 'release-' para ramas de release.

VERSIONAMIENTO CON BAZAAR DEFINICION Bazaar.- Es un sistema de control de versiones distribuido, de origen open source. Busca facilitar el uso de control de versiones distribuido a travs de todas las plataformas. Tiene una interface simple y amigable, para que los nuevos usuarios lo encuentren familiar y natural. CARACTERISTICAS GENERALES Adaptable: Orientado a la mayora de los trabajos de desarrollo de software (local y/o remoto). Amigable: Orientado principalmente a personas que recin empiezan a hacer uso de este tipo de herramientas, enfocado principalmente a la usabilidad y eficiencia. Elegante: Soporta el renombrado de archivos y directorios. Rpido: Permite obtener rpidamente sus ventajas y caractersticas sin afectar al proceso de desarrollo. Eficiente: Su almacenaje utiliza un formato altamente eficiente y limpio. Ligero: No precisa tener un servidor dedicado. Extensible: Posee una arquitectura basada en plugins, aspecto que permite dotarle de mayores caractersticas especificas y acorde a cada necesidad. Embebido: Caracterstica que le permite estar presente en una serie de aplicaciones y servicios libres y/o comerciales. Seguro: Al margen de las caractersticas que posee por si mismo, cuenta con el patrocinio de Canonical tanto para su desarrollo como para su suporte. Libre: Disponible bajo licencia GPL. TERMINOLOGIA Solo: para el desarrollador solitario que necesita control de versiones y publica paquetes. Se tiene un control de versiones sin setup y con control de cambios muy fcil de utilizar.

 Partner: Para trabajar al estilo peer-to-peer, con dos personas que trabajan en sus copias y hacen merge de los cambios de la otra persona cuando sea necesario. Centralizado: Bsicamente el mismo workflow que cvs o subversin, todos los desarrolladores trabajan en el mismo branch, hacen update y luego commit para guardar los cambios en el servidor. Centralizado con commit local: Al trabajar de forma centralizada, se puede hacer un commit local para guardar cambios en el repositorio local y luego enviar todo el set de cambios al repositorio centralizado. Descentralizado con copia principal compartida: Cada desarrollador trabaja con su copia local y luego la envian a la copia principal cuando los cambios estn listos. Descentralizado con rbitro humano: Cada desarrollador tiene su propio branch y acceso de solo lectura al repositorio principal. Cuando un desarrollador quiere publicar sus cambios, le pide autorizacin al rbitro, quien debe revisar el cdigo, y luego publica los cambios en el repositorio principal. Descentralizado con rbitro automtizado: Como el anterior pero una vez enviado al rbitro, ste hace un merge, compila y corre el suite de test, y el cdigo se publica en el servidor principal si y solo si pasa todos los tests. Muy bueno para proyectos grandes y para test driven development. Si los casos de test estan bien mantenidos, este workflow garantiza mayor estabilidad y robustez del cdigo. Bazaar provee una herramienta para esto llamada Patch Queue Manager (PQM) para hacer el trabajo de rbitro automatizado. TIPOS DE COLABORACION Un desarrollador puede trabajar sin interferir con el trabajo de otros desarrolladores. El proceso de fusin es automatizado en su generalidad. Instalacin.

 TIPOS DE ALMACENAMIENTO USO DE RAMAS Working Tree: Cdigo fuente con el que el programador puede trabajar. Todo rbol de trabajo est siempre asociado a una rama (branch). Branch: Guarda el cdigo fuente y el histrico de cambios que se han realizado sobre l. Adicionalmente, se nos permite crear nuevas ramas a partir de una rama, trabajar con ella de forma independiente (con su correspondiente control de versiones) y una vez hayamos acabado podemos volver a fusionarla con la rama inicial.

Veamos un pequeo caso prctico: tenemos una rama base con el cdigo estable y queremos aadir una nueva funcionalidad sin afectar a la estabilidad de ese cdigo. Creamos una nueva rama de desarrollo basada en la rama estable, trabajamos con ella y una vez terminada la nueva funcionalidad y ha sido testeada, fusionamos con la rama estable. Repository: Las ramas de un nico proyecto son muy similares dado que son copias de la misma base junto a nuevas modificaciones, mantener toda esta informacin duplicada puede consumir bastante espacio innecesariamente. Si las ramas son guardadas en un repositorio, estas no mantendrn cada una sus revisiones sino que lo gestionar el repositorio, evitando as la duplicidad de informacin y optimizando el espacio usado.

Cabe destacar que es posible tener la rama (branch) y el rbol de trabajo (working tree) en un mismo directorio, o mantenerlos en directorios separados. Este ltimo caso se suele utilizar para tener las revisiones de control en un servidor centralizado y los rboles de trabajo en los ordenadores de los desarrolladores.