¿Cómo debe formalizarse el contrato de desarrollo por encargo y mantenimiento operativo? — El uso diferenciado del mandato y el contrato de obra, según el «Modelo de transacción y contrato» de la IPA

«Contratamos con un contrato de obra a tanto alzado, pero el desarrollo comenzó sin haber cerrado los requisitos, y terminamos discutiendo sobre cuál era el criterio de finalización.»

«Tenemos un contrato de mantenimiento mensual, pero cada parte entendía de forma distinta hasta dónde llegaba el alcance del mantenimiento.»

«Al pedir un presupuesto, nos dijeron que “la definición de requisitos se hace bajo un contrato de mandato”, pero no entendíamos por qué había que dividir el contrato según cada fase.»

En la externalización del desarrollo de sistemas, no son pocos los problemas que se originan no por cuestiones técnicas, sino por la forma del contrato.

De hecho, existe un “modelo” público para este problema. Se trata del Modelo de transacción y contrato de sistemas de información, publicado por la IPA (Agencia Independiente de Promoción de Tecnologías de la Información).

En este artículo, tomando como base este modelo de contrato, organizamos, en términos comprensibles también para el cliente contratante, cómo debería estructurarse el contrato al encargar o al recibir un encargo de desarrollo por encargo y de operación y mantenimiento.

Cabe señalar que este artículo es una explicación general basada en material público de la IPA y no constituye asesoría legal. Para casos concretos de contratación, consulte con un abogado u otro profesional especializado.

1. La conclusión, primero

Resumimos primero el enfoque que plantea el Modelo de transacción y contrato de la IPA sobre los contratos de desarrollo de sistemas y de operación y mantenimiento.

• No agrupar todas las fases del desarrollo en un solo contrato, sino dividir el contrato según cada fase (contrato por etapas)
• Formalizar como contrato de mandato la fase de planificación y definición de requisitos, en la que aún no está decidido “qué se va a construir”
• Formalizar, en principio, como contrato de obra las fases que van desde el diseño interno hasta el desarrollo y las pruebas, una vez decidido “qué se va a construir” (el diseño externo puede ir en cualquiera de los dos según el caso)
• Formalizar como contrato de mandato, en principio, las tareas continuas como la operación y el mantenimiento
• El cliente contratante también tiene obligaciones de cooperación, como decidir los requisitos y proporcionar información
• No gestionar los cambios de especificación de palabra, sino tratarlos mediante un procedimiento documentado de gestión de cambios

En una frase: el principio es “no prometer responsabilidad de finalización sobre lo que aún no está decidido, y sí prometerla sobre lo que ya está decidido”, usando una u otra forma de contrato según la fase.

2. Qué es el «Modelo de transacción y contrato de sistemas de información» de la IPA

El Modelo de transacción y contrato de sistemas de información es un documento público que reúne una plantilla de contrato de externalización del desarrollo de sistemas junto con su explicación.

Originalmente, el Ministerio de Economía, Comercio e Industria (METI) lo publicó en 2007 como la primera versión, orientada al desarrollo por encargo (incluyendo parte de la planificación) y a la operación y el mantenimiento. El trasfondo era que existían frecuentes desajustes de percepción sobre el contenido del contrato entre la empresa usuaria (cliente contratante) y el proveedor de TI (contratado), lo que generaba muchos problemas.

Posteriormente, la IPA se hizo cargo de la revisión, y en respuesta a la reforma del Código Civil que entró en vigor en abril de 2020, se publicó la segunda versión el 22 de diciembre de 2020. En la segunda versión se ordenaron, entre otros puntos, la responsabilidad por falta de conformidad contractual (que se explica más adelante) y la posición del contrato de mandato orientado a resultados.

Hay que prestar atención al ámbito de aplicación. Esta primera y segunda versión se elaboraron originalmente pensando en desarrollo a medida de tamaño relativamente grande (de tipo cascada), como los sistemas troncales de las empresas, para transacciones entre compañías que cuentan con departamento de sistemas y área jurídica propios. Para transacciones de tamaño pequeño o mediano, o para los casos que aprovechan paquetes o SaaS/ASP, se ha preparado por separado una serie de modelos de contrato tipo “suplemento”, orientados a “uso de paquetes, SaaS/ASP, operación y mantenimiento”. La distancia correcta es confirmar primero cuál de las dos se acerca más a la transacción de la propia empresa, y usar el modelo no como texto para copiar literalmente, sino como base de razonamiento. Lo que presentamos en este artículo es precisamente esa parte de “razonamiento”, útil sea cual sea el tamaño de la transacción.

Este modelo de contrato tiene las siguientes características.

• Fue elaborado mediante discusión entre empresas usuarias, proveedores de TI, asociaciones sectoriales y expertos legales, diseñado de forma neutral para no favorecer a ninguna de las partes
• La plantilla del contrato se publica en formato Word y puede modificarse para adaptarla a la transacción de cada empresa
• No incluye solo las cláusulas, sino también una explicación de “por qué se establece así”
• También se publican documentos anexos, como una guía para definir las especificaciones de seguridad del contrato de desarrollo

En definitiva, es un material que sirve tanto como borrador de partida al elaborar un contrato como criterio de comparación al revisar un contrato presentado por la contraparte.

Qué versión conviene consultar

En la página de la IPA aparecen varias versiones, así que conviene decidir primero cuál se parece más a la transacción de la propia empresa antes de abrirlas, para no perderse.

La explicación que sigue en este artículo toma como base el cuerpo principal de la segunda versión, que es el más fundamental.

3. El núcleo es el “contrato por etapas”: por qué se divide el contrato según cada fase

El núcleo del enfoque del Modelo de transacción y contrato es el contrato por etapas.

El desarrollo de sistemas avanza, a grandes rasgos, según las siguientes fases.

Planificación y definición de requisitos (decidir qué se va a construir)
        ↓
Diseño, desarrollo y pruebas (construir lo decidido)
        ↓
Aceptación y soporte a la implantación (poner lo construido en producción)
        ↓
Operación y mantenimiento (mantenerlo funcionando)

El contrato por etapas es un método que, en lugar de agrupar estas fases en un solo contrato, divide el contrato según cada fase (o según cada conjunto de fases).

La estructura documental real: dos capas, el contrato básico y el contrato individual

Al oír “dividir el contrato según cada fase” se podría pensar que se elabora un contrato independiente por cada fase, pero lo que adopta el modelo de contrato es una estructura de dos capas: el contrato básico y el contrato individual. Conviene fijar primero esta estructura para no desorientarse al abrir la plantilla.

• Modelo de contrato básico de externalización del desarrollo de software (contrato básico) — Establece los asuntos comunes a todo el proyecto y, en principio, se firma uno por proyecto. Aquí se incluyen cláusulas como la definición de términos, la subcontratación, la colaboración y el reparto de roles, los responsables, el comité de enlace, el procedimiento de gestión de cambios, la confidencialidad, la propiedad intelectual y la indemnización por daños.
• Contrato individual — Se firma para cada tarea concreta, antes de comenzar a trabajar en ella. Son unidades como el soporte para la elaboración de la definición de requisitos, la elaboración (o el soporte a la elaboración) del documento de diseño externo, el trabajo de desarrollo de software, o el soporte a la preparación y migración de la puesta en operación del software. Aquí se decide el contenido y el alcance concreto del trabajo, el tipo de contrato (obra o mandato), el período de trabajo o el plazo de entrega, el detalle del reparto de roles, la remuneración y la forma de pago, los entregables, y los asuntos relativos a la inspección y verificación.

Es decir, todo lo que “cambia según la fase” se ha desplazado al lado del contrato individual, y también en el contrato individual es donde se decide si se opta por obra o por mandato. El contrato básico establece además que sus cláusulas prevalecen sobre las del contrato individual.

La operación y el mantenimiento cuentan con un contrato distinto del de desarrollo (el Modelo de contrato básico de externalización de operación y mantenimiento de sistemas de información), que también sigue las mismas dos capas de contrato básico y contrato individual. Como la operación y el mantenimiento abarcan un tipo de trabajo muy diverso y no es posible crear una plantilla uniforme, se explicita el enfoque de colocar solo las cláusulas comunes en el contrato básico y definir cada tarea encargada en el contrato individual. Al contrato individual se prevé anexar la especificación del trabajo, donde se describe el contenido del servicio estandarizado, y el detalle de las condiciones de encargo, donde se describen los asuntos que varían según el cliente, como el sistema objeto, el lugar de ejecución o el reparto de roles.

Los documentos contractuales incluidos en el cuerpo principal de la segunda versión son los siguientes.

¿Por qué se divide? La razón es simple: lo que “se puede prometer” varía según la fase.

Antes de que termine la definición de requisitos, ni el contenido ni el volumen de lo que se va a construir están decididos. Si en este punto se fija el importe y el plazo de todo el desarrollo, ocurre una de estas dos cosas:

• El proveedor presenta un importe elevado que anticipa el riesgo de lo incierto
• El proveedor, tras haber aceptado un precio bajo, alega después que “eso está fuera de alcance”, y entra en conflicto con el cliente contratante

En cambio, si la definición de requisitos ya está terminada, lo que se va a construir está decidido, de modo que el proveedor puede ofrecer un presupuesto y una promesa de finalización con una precisión realista.

El contrato por etapas es un método que presupone que “en el momento en que termina la definición de requisitos, se vuelve a presupuestar la parte de desarrollo”. Visto desde el cliente contratante, existe la inquietud de que el importe total no quede fijado desde el principio, pero la postura del modelo de contrato es que, en comparación con fijar el conjunto con un importe sin fundamento, este método reduce, en definitiva, tanto los conflictos como el costo desperdiciado.

4. Mandato y obra: la diferencia entre los dos tipos de contrato

En el contrato por etapas, se usa de forma diferenciada el contrato de mandato y el contrato de obra según cada fase. Esta diferencia es el punto más importante de este artículo.

Resumimos brevemente antes los términos que aparecen en este capítulo.

A partir de esto, resumimos en una tabla la diferencia entre obra y mandato.

El contrato de obra: un contrato que promete la finalización

La obra es un contrato en el que se promete “completaré este entregable”. El contratado asume la responsabilidad de finalización y, en principio, no puede reclamar la remuneración si no se completa el trabajo (no obstante, aun si el proyecto termina a mitad de camino, cuando la parte ya completada pueda separarse y beneficie al cliente contratante, en algunos casos se reconoce una remuneración proporcional a esa parte).

Si lo entregado no se ajusta al contenido del contrato, el contratado asume la responsabilidad por falta de conformidad contractual. Se trata de un concepto reconstruido a partir de la anterior “responsabilidad por vicios ocultos” mediante la reforma del Código Civil vigente desde 2020: el cliente contratante puede exigir la reparación (que se corrija), y además, bajo ciertas condiciones —por ejemplo, cuando se fija un plazo para pedir la reparación y esta no se realiza—, también puede exigir una reducción de la remuneración. Sin embargo, si la falta de conformidad se origina en las propias especificaciones o instrucciones presentadas por el cliente contratante, en principio no pueden hacerse estas reclamaciones, salvo en casos como que el contratado se haya dado cuenta del problema y no lo haya comunicado. La segunda versión del modelo de contrato refleja esta reforma.

Al tratarse de un contrato en el que se asume una responsabilidad fuerte a cambio de la finalización, es adecuado usarlo en fases donde se pueda decidir con claridad “qué se considera finalización”.

El contrato de mandato: un contrato que promete el trabajo como profesional

El mandato es un contrato en el que se promete “realizaré el trabajo como profesional”. A cambio de no asumir responsabilidad de finalización, el contratado asume el deber de diligencia de un buen administrador, es decir, la obligación de ejecutar el trabajo con la atención que normalmente se espera de un profesional.

Al oír “no hay responsabilidad de finalización”, al cliente contratante puede sonarle inquietante. Pero esto no significa “que se pueda trabajar sin esmero”. Si el trabajo se realiza de forma inadecuada para un profesional, se puede exigir responsabilidad por incumplimiento del deber de diligencia.

Además, la reforma del Código Civil formalizó también una forma de pago del mandato llamada orientada a resultados. Frente al tipo por proporción de ejecución, que paga la remuneración según la proporción del trabajo realizado (la liquidación por tarifa horaria es el ejemplo representativo, y también puede tomar la forma de una tarifa mensual fija para trabajo estandarizado), el tipo orientado a resultados paga la remuneración a cambio del resultado acordado. En trabajos de mandato que tienen un entregable, como el documento de definición de requisitos, usar este tipo permite lograr una forma en la que “es un mandato, pero la entrega del resultado está vinculada a la remuneración”.

Uso diferenciado según la fase

En el Modelo de transacción y contrato se contempla, a grandes rasgos, el siguiente uso diferenciado.

Aquí lo importante es que no se trata simplemente de que “la obra favorece más al cliente contratante” o “el mandato favorece más al contratado”.

Si se fuerza a que un trabajo en una fase aún no decidida se formalice como obra, se termina prometiendo solo la responsabilidad de finalización con un criterio de finalización ambiguo, lo que desemboca en una discusión estéril sobre si “está terminado o no está terminado”. Elegir el tipo de contrato adecuado a la naturaleza de la fase es, en definitiva, lo que protege a ambas partes.

5. Qué se debe decidir en el contrato de operación y mantenimiento

La operación y el mantenimiento, una vez terminado el desarrollo, contienen una fuente de conflictos distinta de la del desarrollo. La más frecuente es el desajuste de percepción sobre “hasta dónde está incluido en la tarifa mensual de mantenimiento”.

Aunque se hable de “operación y mantenimiento” como un solo concepto, en realidad es un conjunto de tareas de naturaleza diversa.

• Monitoreo del funcionamiento, copias de seguridad, mantenimiento periódico
• Atención de consultas, como sobre el modo de uso
• Investigación inicial y respuesta de recuperación cuando ocurre una falla
• Corrección de defectos
• Seguimiento de las actualizaciones del sistema operativo y del middleware
• Mejoras como la adición de funciones o cambios de pantalla

De estas, las tareas continuas como el monitoreo, la atención de consultas y la investigación inicial son, en principio, de tipo mandato. En cambio, las mejoras o adiciones de función cuyo contenido se puede definir con claridad es más seguro no incluirlas de forma ambigua dentro del contrato de mantenimiento, sino presupuestarlas por separado y formalizarlas como obra.

Como en palabras es difícil hacerse una idea concreta, damos ejemplos de dónde se suele trazar la línea. Dónde se traza la línea es algo que decide el contrato, así que esto es, en todo caso, “un desenlace habitual”.

La cuarta fila, “agregar un elemento a una pantalla”, parece menor desde el punto de vista de quien lo solicita, pero en realidad pone en marcha todo el conjunto de diseño, implementación, pruebas y publicación. Fijar de antemano un criterio de una sola línea que no deje margen a la interpretación, como “las solicitudes que aumentan o reducen elementos de una pantalla o de un informe se presupuestan aparte”, reduce las negociaciones caso por caso.

Se recomienda decidir por escrito, al menos, los siguientes puntos al momento del contrato:

• La línea que separa el trabajo incluido en el alcance mensual (fijo) del que no lo está
• El horario de recepción de consultas y respuestas a fallas, y el tiempo estimado hasta el inicio de la atención
• La clasificación de la gravedad de las fallas y la política de respuesta según cada clasificación
• El procedimiento de presupuesto y encargo cuando surge un trabajo que excede el alcance fijo
• La relación entre la responsabilidad por falta de conformidad contractual del contrato de desarrollo (objeto de corrección sin cargo) y el contrato de mantenimiento (respuesta pagada)

El último punto en particular suele pasarse por alto. Si un defecto detectado justo después de la entrega entra en el alcance de la responsabilidad por falta de conformidad contractual del contrato de desarrollo, o si corresponde a la atención del contrato de mantenimiento, es un punto que fácilmente genera conflicto si el período y las condiciones no se dejan claros en el contrato.

6. El cliente contratante también tiene obligaciones: el deber de cooperación y el deber de gestión de proyecto

Nos alejamos un poco del tema de los contratos, pero hay una idea importante que se repite tanto en la explicación del Modelo de transacción y contrato como en la jurisprudencia acumulada hasta ahora. El desarrollo de sistemas es un trabajo conjunto entre el cliente contratante y el proveedor, y ambas partes tienen obligaciones que deben cumplir.

• El proveedor, como profesional, asume el deber de gestionar adecuadamente el proyecto y de explicar los riesgos si los hay (deber de gestión de proyecto)
• El cliente contratante asume un deber de cooperación que incluye decidir los requisitos, proporcionar información sobre el contenido del negocio y tomar las decisiones necesarias dentro de plazo

En otras palabras, si el cliente contratante delega todo en el proveedor con la idea de “como no entiendo de temas técnicos”, es decir, si hace lo que se conoce como una delegación total, los requisitos no se consolidan, y cuando el proyecto fracasa, también puede cuestionarse el cumplimiento del deber de cooperación por parte del cliente contratante.

El Modelo de transacción y contrato incorpora un mecanismo para documentar el reparto de roles entre ambas partes y compartir el avance y los problemas en un comité de enlace (reunión periódica). Leído no tanto como una plantilla de contrato sino como un libro de reglas para gestionar el proyecto en conjunto, es un material del que también el cliente contratante puede obtener mucho provecho.

7. Los cambios de especificación se tratan mediante el “procedimiento de gestión de cambios”

Es inevitable que, durante el desarrollo, surja la petición de “en realidad quiero cambiar esta pantalla de tal forma”. El problema no es que surja el cambio en sí, sino que el cambio se tramite únicamente mediante intercambios verbales o por correo electrónico.

• El cliente contratante entiende que “pensaba que era un cambio menor”
• El proveedor entiende que “se atendió, pero como el esfuerzo se infló, quiero cobrar un costo adicional”

Los intercambios verbales o por correo electrónico también quedan como registro de la negociación, pero, al no existir un documento en el que ambas partes hayan acordado formalmente el alcance, el costo y el plazo del cambio, una vez que se llega a este punto es fácil caer en una discusión estéril de “él dijo, ella dijo”.

El Modelo de transacción y contrato establece un procedimiento de gestión de cambios. A grandes rasgos, el flujo es el siguiente.

Propuesta de cambio (por cualquiera de las partes)
        ↓
Presentación por escrito (propuesta de cambio) del contenido, el alcance del impacto, el costo y el efecto en el plazo
        ↓
Negociación entre ambas partes
        ↓
Si hay acuerdo, se deja constancia por escrito y se ejecuta el cambio / si no hay acuerdo, se mantiene lo vigente

El punto clave es acordar, antes de comenzar, no solo el contenido del cambio, sino también su efecto sobre el costo y el plazo, en conjunto. Como procedimiento representa un paso adicional, pero es precisamente este paso adicional el que evita el conflicto de “él dijo, ella dijo”.

8. En el caso del desarrollo ágil, existe un modelo de contrato específico

Lo explicado hasta aquí es el contrato pensado para el modelo en cascada, en el que se construye después de decidir los requisitos.

Por otro lado, para el desarrollo ágil, en el que los requisitos se revisan a medida que se construye, se publicó el 31 de marzo de 2020 un modelo de contrato específico llamado Modelo de transacción y contrato de sistemas de información (versión para desarrollo ágil).

Las características de la versión para desarrollo ágil son las siguientes.

• El tipo de contrato parte de la base del contrato de mandato. Se trata de un método que presupone añadir o modificar funciones y revisar las prioridades durante el desarrollo, lo cual no encaja con la obra, que fija el entregable desde el principio
• Adopta Scrum como método de desarrollo e incorpora el reparto de roles (como el de propietario de producto) dentro del contrato
• Incluye una lista de verificación previa al contrato, con la que el cliente contratante y el proveedor confirman, antes de avanzar hacia el contrato, el objetivo del proyecto y el grado de comprensión del desarrollo ágil

No se trata de que “por ser ágil, el contrato pueda ser ambiguo”, sino de un diseño en el que, precisamente por ser un desarrollo que responde al cambio, los roles y la forma de avanzar se dejan claros en el contrato.

Resumen

Organizamos las ideas sobre el contrato de desarrollo por encargo y de operación y mantenimiento que se pueden aprender del Modelo de transacción y contrato de sistemas de información de la IPA.

• No agrupar todo el desarrollo en un solo contrato, sino dividir el contrato según cada fase (contrato por etapas)
• La planificación y definición de requisitos, en la que se decide qué se va a construir, se formaliza como mandato; el desarrollo posterior al diseño interno, que construye lo ya decidido, se formaliza en principio como obra (el diseño externo puede ir en cualquiera de los dos)
• La obra implica responsabilidad de finalización y responsabilidad por falta de conformidad contractual; el mandato implica el deber de diligencia de un buen administrador: la naturaleza de la responsabilidad que asume el contratado es distinta en cada caso
• La operación y el mantenimiento se formalizan, en principio, como mandato, dejando por escrito, al momento del contrato, la línea entre el alcance de la tarifa fija y el presupuesto individual
• El cliente contratante también tiene un deber de cooperación, y la delegación total hace fracasar el proyecto
• Los cambios de especificación se canalizan a través del procedimiento de gestión de cambios, acordando en conjunto su efecto sobre el costo y el plazo
• El desarrollo ágil cuenta con un modelo de contrato específico basado en el mandato

La plantilla del modelo de contrato y su explicación pueden descargarse de forma gratuita en formato Word desde el sitio web de la IPA. Tanto quien esté por externalizar un desarrollo como quien haya recibido un contrato para revisar, es un material que vale la pena leer al menos una vez.

Para quienes estén considerando externalizar el desarrollo o el mantenimiento de un sistema

Para elegir adecuadamente la forma del contrato, es necesario, como premisa, tener claro “qué se va a construir”, “hasta dónde se va a externalizar” y “cómo se reparten los roles entre el cliente contratante y el contratado”.

En KomuraSoft LLC, al recibir consultas sobre desarrollo por encargo y mantenimiento de aplicaciones empresariales para Windows y sistemas web, proponemos, siguiendo el enfoque de contrato por etapas presentado en este artículo, separar la etapa de organización de requisitos de la etapa de desarrollo. Incluso si todavía falta organizar el alcance del desarrollo o los entregables, puede consultarnos desde la simple confirmación del contenido actual del trabajo.

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Cuál es la diferencia entre el contrato de obra y el contrato de mandato?

El contrato de obra es un contrato en el que se paga la remuneración a cambio de "completar el entregable acordado", y el contratado asume la responsabilidad de finalización y la responsabilidad por falta de conformidad contractual. El contrato de mandato es un contrato en el que se paga la remuneración a cambio de "realizar el trabajo como profesional" (en el mandato orientado a resultados, se paga la remuneración por el resultado acordado), y el contratado asume el deber de diligencia de un buen administrador (la obligación de realizar el trabajo con atención, como profesional), pero no asume la responsabilidad de finalización. La obra es adecuada para las fases en las que se puede definir con claridad qué se va a construir y cuál es el criterio de finalización; el mandato es adecuado para las fases en las que se apoya un estudio liderado por el cliente contratante, o para el trabajo continuo.

¿Por qué se recomienda el contrato de mandato para la definición de requisitos?

Porque la definición de requisitos es una fase en la que el cliente contratante es quien decide, de forma protagonista, "qué se va a construir", mientras que el proveedor ocupa la posición de apoyar ese estudio. Además, como al comienzo es difícil fijar de forma concreta el entregable, si en esta etapa se promete la responsabilidad de finalización (obra), el criterio de finalización queda ambiguo y se convierte en causa de conflicto. En el Modelo de transacción y contrato de la IPA también se contempla el tipo mandato para la fase de planificación y definición de requisitos.

¿Qué conviene más para el contrato de operación y mantenimiento, obra o mandato?

Las "tareas continuas" como el monitoreo del funcionamiento, la atención de consultas o la investigación inicial de fallas no encajan con el concepto de finalización, por lo que el tipo mandato es la base. Por otro lado, las adiciones de función o las mejoras de pantalla cuyo contenido y criterio de finalización se pueden definir con claridad se pueden separar de forma individual y contratar como obra. Es importante dejar por escrito, al momento del contrato, la línea entre lo que está incluido en el contrato de mantenimiento mensual y lo que se presupuesta aparte.

¿Se puede usar tal cual el Modelo de transacción y contrato de la IPA?

El modelo de contrato se publica en formato Word, y su premisa es que se modifique para adaptarlo a la transacción de la propia empresa. Como está elaborado desde una posición neutral que no favorece ni a la empresa usuaria ni al proveedor de TI, resulta útil como borrador de partida para un contrato o como criterio de comparación al revisar un contrato presentado por la contraparte. No obstante, para las decisiones contractuales concretas, se recomienda consultar con un abogado u otro profesional especializado.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.