Los programadores hacen programas
Los ingenieros hacen artefactos de software

Que es un programa y para que invertir en hacerlos? ...

Coleccion de conceptos clasicos imprescindibles

➽Para que hacer programas?. Es la pregunta clasica de un ingeniero
 Un programa se crea para  ser la solución o  parte de la solución de un problema que requiere datos y transformaciones.

➽Un programa representa un plan , desde la entrada a la salida , para la solución automática de un problema , es un medio para conseguir un fin; es un proceso a ser realizado sobre datos
una secuencia de acciones sobre  datos,  generando cambios de estados en ellos, para un fin bien definido


➽J.D. warnier
Un programa debe ser facil de modificar y confiable. Pero ante todo, debe ser util para el ususario final. Por esta razon , los datos de salida deben ser definidos por los usuarios finales y no por el espeialista en procesamiento de datos. Cuado los requerimientos del usuario final estan definidos , pude diseñarse el conjunto logico de datos para el sistema poniendo atencion en la estructura de datos  y la mejor organizacion de los archivos fisicos y de la base de datos.

➽Albert C. Gardner
que es un programa? ... es un medio para conseguir un fin
Objetivo del diseño de programas:
excluyente: producir un programa "correcto", por ejemplo, uno que , dada cualquier combinacion de datos de  entrada aceptable , siempre llegue al final del proceso y produzca los resultados previstos.
Subsidiariamente:
1-el programa debe ser fácil de mantener , es decir fácil de corregir por cualquier razón
2- que el programa pueda desarrollarse rápidamente
3- que le programa sea eficiente en el empleo de los recursos de maquina


➽fácil de mantener , significa fácil de cambiar.
Cambiar porque el programa es erroneo (en ciertas circunstancias no produce la salida correcta)
cambiar porque han variado los requerimientos
1- cuantos menos lugares o puntos del programa sea necesario cambiar , con mas rapidez se localizaran y sera menor el riesgo de errores.
2-cuanto mayor sea la correspondencia : puntos a alterar con circunstancias especificadas ( o sea que los bloques del programa a cambiar sean pertinentes únicamente al cambio requerido)
La facilidad  de mantenimiento se obtiene por lo tanto;
1- conservando la menor cantidad de subdivisiones en el programa
2- conservando bloques distintos  de instrucciones en el programa para cada clase diferente de datos
Eficiencia

Las instrucciones a aplicarse a un elemento o parte de datos son de dos tipo
1-las que determinan que conjunto de acciones se requieren para cada elemento
2-las  que realizan las acciones

las de tipo (1) son las que deben analizarse
una idea de eficiencia podrá tenerse contando la cantidad de secuencias y cantidad de evaluaciones que necesita cada una de ellas

➽Langefors
La informacion se necesta para iniciar y controlar los acontecimientos operativos.
Hemos encontrado los flujos minimos (operaciones) que debn ser mantenidos operativamente y notamos que en a practica los flujos son realente una serie de acontecimientos operativos.
Ahora es facil comprender que cada acontecimiento de estos flujos deben ser activado y guiado por mensajes apropiados, a los que llamamos informacion operativa o informacion de rutina.

si se usan relaciones (de precedencia) estructuras de datos y algoritmos comprendemos que los datos tienen un significado

➽Un programa representa un plan , desde la entrada a la salida , para la solucion automatica de un problema que incluye la transcripcion de los datos, codificacion , absorcion del resultado o rutinas alternativas
➽Un programa es la especificación de un proceso a ser realizado con los datos

el resultado del análisis de información para un problema o un sistema es la documentacion de las clases de información requeridas. estas están relacionadas entre si mediante relaciones de precedencia. Por lo tanto , un análisis de la informacion define el agrupamiento de precedentes de cada informacion que debe ser producida
las entradas y salidas del programa surgen del agrupamiento de precedentes. mas aun debe especificarse cuales de los precedentes activan el proceso
➽Se desea poder decir que debe ser hecho por el proceso y dejar a la decisión del diseñador del programa la decisión de los pasos de los procesos individuales que deben ser realizados por el computador

La sola existencia de los precedentes no necesariamente inicia su proceso , hay que describir la informacion de control requerida para su ejecucion
relaciones de precedencia + estructura de datos + algoritmos= sistemas

➽Niklaus wirth
la esencia del poder y de la amplia aplicación de la computadora reside en su capacidad de ejecutar secuencias extremadamente largas de instrucciones que contienen una combinación casi infinita de acciones elementales. La acción de integrar secuencias de instrucciones en "recetas" que representan ciertas clases de procesos de  calculo se llama programación

La noción mas importante es la de acción en este contexto suponemos que una acción es de duración finita , y que persigue algún efecto bien definido. Toda acción requiere la existencia de algun objeto sobre el cual se ejecuta y podemos reconocer el efecto de a acción a través de los cambios de estado que sobre el se operen.
Cada acción debe poder describirse en términos de algún lenguaje o sistema de formulas; su descripción se llamara enunciado.
Si la acción puede descomponerse en partes la llamaremos proceso o calculo. El proceso sera secuencial si estas partes se siguen estrictamente unas a otras en el tiempo, y nunca se ejecutan dos simultáneamente. De la misma forma un enunciado que describe un proceso puede subdividirse en partes; en ese caso se lo llama programa.
Un programa , entonces , consta de un conjunto de enunciados cuyo orden textual no suele ser en gral identico al ordenamiento en el tiempo de las acciones correspondientes
Todo programa describe una sucesion de transformaciones sobre el conjunto de sus variables.
Si el mismo programa se ejecuta dos veces con valores iniciales (x,y) diferentes , seria un error afirmar que los dos procesos son iguales. sin embargo ambos exhiben el mismo comportamiento.
Ls descripción de ese comportamiento sin hacer referencia a un procesador en particular se llama usualmente algoritmo.
Algoritmo + Estructua de datos=Programas

Formulcion del problema

tomada de : https://msaffirio.wordpress.com/2017/04/27/la-identificacion-del-problema-o-necesidad/

La primera acción formal de la ejecución de un proyecto, cualquiera sea su tipo, es identificar el problema o necesidad que se pretende resolver. A objeto de evitar ambigüedades incluyo la definición de problema de acuerdo con los diccionarios.

Problema según el Diccionario de la RAE (Real Academia Española):

Del lat. problēma, y este del gr. πρόβλημα próblēma.

m. Cuestión que se trata de aclarar.

m. Proposición o dificultad de solución dudosa.

m. Conjunto de hechos o circunstancias que dificultan la consecución de algún  ……fin.

m. Disgusto, preocupación. U. m. en pl. Mi hijo solo da problemas.

m. Planteamiento de una situación cuya respuesta desconocida debe obtenerse a través de métodos científicos.

Problem según Concise Oxford Dictionary (1995):

“A doubtful or difficult matter requiring a solution”.

 (Una cuestión dudosa o difícil que requiere solución).

                        and

“Something hard to understand or accomplish or deal with”.

(Algo difícil de entender o lograr o trata).

Para evitar un desajuste en lo que usted entrega, y lo que el cliente desea es indispensable estar de acuerdo con la definición del problema real, entender que un problema en una empresa puede ser percibido de manera distinta según sea la persona que lo observe. A veces se confunden con los síntomas o con los deseos y gustos personales.

Un problema o nueva actividad, o nuevo producto, o nuevo proyecto en el lugar de trabajo se crea en respuesta a una necesidad del negocio. Y, que precisa ser definido de la mejor forma posible a objeto de no malgastar tiempo ni recursos.

A continuación, describiré un método para identificar el Problema o Necesidad, que en estricto rigor corresponde al Análisis de Requerimiento [1], asumiendo que las acciones necesarias para resolver el problema; es decir, la solución del Problema o Necesidad constituyen, primero un Anteproyecto y, después un Proyecto.

Identificar a las Partes Interesadas

¿Por qué son importantes?

Las Partes Interesadas –Stakeholders- son personas, grupos, u organizaciones que pueden afectar a la solución del problema o al proyecto, o pueden ser afectadas por la solución del problema, o perciben que puede ser afectadas por decisiones, actividades, o resultados del proyecto, cuyo objetivo es resolver el problema.

Las Partes Interesadas pueden estar activamente involucradas en la solución del problema o pueden tener intereses que pueden afectar negativa o positivamente el devenir del proyecto que resolverá el problema. Existen diferentes Partes Interesadas que pueden tener expectativas que entran en conflicto con la solución del problema. En definitiva, las Partes Interesadas pueden ejercer influencia sobre la identificación del problema o necesidad, sea por acción u omisión.

 ¿Quiénes son las Partes Interesadas?

Para el caso de la Identificación del Problema es necesario conocer quienes son las Partes Interesadas; es decir identificar a todas las personas relacionadas con el Problema que se pretende resolver, mediante la ejecución de un proyecto. Como también todas la entidades internas o externas que tengan intereses o relación con el problema.

Quién esté designado para ejecutar la tarea de identificación del Problema debe individualizar y calificar a las Partes Interesadas, considerando:

• Si son internas o externas a la organización.
• Si tienen una actitud positiva o negativa respeto del proyecto.
• Si participarán en forma activa o como consejeros.

 Ranking de Interés e Influencia

Cada proyecto tiene “Partes Interesadas”, formando el “elemento humano” del paradigma de la gestión de proyectos. Como su nombre indica, un grupo de interés del proyecto es cualquier persona o entidad con una apuesta en el proyecto —tienen algo que perder y/o algo que ganar. Esta apuesta impulsa el comportamiento, y el comportamiento impulsa los resultados.

Para el éxito del proyecto, con un mínimo de conflictos, es necesario lograr que todos los interesados estén totalmente comprometidos y motivados. El compromiso y la participación infunden orgullo de la propiedad, lo que lleva a mejores resultados, entregados de una manera más productiva. La capacidad de enganchar comienza con una comprensión completa de la identidad de los involucrados y el papel  que tienen asignado, los intereses creados, la responsabilidad y el poder de influir en los resultados finales. En términos de procedimiento, este entendimiento se obtiene a través del análisis de los interesados.

i. Identificar las Partes Interesadas

Consiste en determinar cuáles son las personas que de alguna u otra manera participan y/o influyen en la identificación del Problema o Necesidad, y a la vez establecer cuál será el rol que desempeñaran. La siguiente es una lista con los roles comunes:

• Los Beneficiarios: Grupo / Persona que recibe un beneficio de la solución del problema.
• Los Líderes: Grupo / Persona responsable de la gestión de la ejecución de la solución del problema o proyecto.
• El Equipo del Proyecto: Grupo / Persona responsable de la ejecución del proyecto.
• El Patrocinador: Grupo / Persona responsable de la supervisión y el patrocinio.
• Los Asesores: Grupo / Persona responsable de asesorar y supervisar la identificación del Problema.

ii. Establecer Quienes Tienen Interés en la Solución del Problema (Proyecto)

Se utilizan dos dimensiones para establecer el interés en el resultado de la solución

• Interés determinado por el Impacto. Cada solución de un problema o necesidad tiene consecuencias, que se manifiestan en una variedad de formas y grados (operativos, financieros y personales). La solución de un problema o necesidad puede cambiar la forma en que se realiza el trabajo, disminuir la responsabilidad, añadir más responsabilidad, perder poder y similares. El impacto se puede sentir de muchas maneras, tanto obvias y como sutiles.
• Interés determinado por la Responsabilidad. Es sabido que la responsabilidad —Accountability- es un gran motivador. La rendición de cuentas se define por el grado en el que un actor se hace responsable por su papel en la solución del problema o proyecto, ya sea para ejecutar tareas asignadas, por las decisiones que toma, por el apoyo que proporciona, por su participación, actitud y contribuciones globales. Cuanto más “responsabilidad” mayor interés.

iii. Determinar Quién Tiene el Poder de Hacer una Diferencia

Se necesita mucho esfuerzo para hacer que un proyecto sea exitoso, pero sólo se necesita un pequeño acto para deshacer ese esfuerzo y tornar las cosas en la dirección equivocada. La gente (y grupos) tienen el poder para conducir los proyectos al éxito o desviar el resultado a situaciones no deseadas. Esta es la moneda de dos caras conocida como la influencia de las Partes Interesadas. En la parte positiva, la participación activa de los interesados; sin duda, tendrá una influencia positiva en el proyecto y / o proceso, y esta posibilidad debe ser cultivada. En el lado negativo, los interesados también tienen la capacidad de influencia negativa, por medio de: falta de cumplimiento, indecisión, falta de apoyo, dilación, retención de información, y similares. Para facilitar el análisis de los interesados, la influencia potencial está determinada en gran parte por la fuerza de las consecuencias probables para cada persona.

Asegúrese de que su lista esté completa: recuerde, las Partes Interesadas afectadas por el Problema o con la Necesidad podrían estar todos en una división o departamento, o podrían estar repartidos entre varios departamentos o niveles de la organización.

iv. Validar la lista de las Partes Interesadas a Entrevistar

Una vez identificadas las Partes Interesadas validar la lista con el Patrocinador —Sponsor- de la Iniciativa y/o con los Ejecutivos que autorizaron ejecutar las acciones para identificar el Problema, así mismo establecer con ellos con quienes se hará la verificación, revisión y generación de la versión final de la Definición del Problema.

Situación Actual

Para que las Partes Interesadas —Stakeholders– comprendan el problema o la necesidad es indispensable que, en primer lugar, que conozcan y entiendan como se están haciendo las cosas ahora en el área afectada de su organización. Esto es lo que en proceso de negocios se denomina as-is.

Es común que las Partes Interesada conozcan sólo una parte del proceso asociado con el problema, en particular cuando el problema afecta a varios departamentos o gerencias.

La primera tarea es precisar la situación actual del entorno donde se está produciendo el problema o la oportunidad de mejoramiento, como ser:

• Operación as-is. Procedimientos. Reglas de Negocios
• Procesos de Negocios afectados.
• Personal involucrado.
• Estructura organizacional. Gerentes. Supervisores y Operativos.
• Sistemas o aplicaciones computacionales.
• Infraestructura, Tecnología.
• Países donde se opera.
• Adquisición de otra empresa.
• Apertura de una nueva locación.
• Obligaciones Legales.
• Clientes afectados.
• Sobre gastos, mermas, pérdida de venta, etc.

Para ello debe ejecutar entrevistas a las Partes Interesadas con o sin interés en resolver el problema, esto permite comprobar si el problema es una necesidad del negocio o un requerimiento personal. Tener en cuenta que producto de las entrevistas pueden evidenciarse situaciones conflictivas entre las Partes Interesadas, que es necesario considerar con el debido cuidado.

i. Entrevistas a Las Partes Interesadas para establecer la situación as-is

El objetivo principal de las entrevistas es obtener de las Partes Interesada cual es el Problema o Necesidad de negocio que se precisa solucionar, averigüe que quieren y que esperan de la solución del Problema. [2]

Puede utilizar varios métodos para comprender y capturar la información de las Partes Interesadas, como ser:

• Uso de entrevista. Converse con cada Parte Interesada individualmente. Esto le permite entender las opiniones y necesidades específicas de cada persona.
• Realizar talleres. Esto le ayuda a entender cómo fluye la información entre las diferentes divisiones o departamentos o personas y, asegurarse de que las transferencias y coordinaciones se gestionarán sin problemas.

Al usar estos dos métodos, es una buena idea seguir preguntando “¿Por qué?” para cada requisito. Esto puede ayudarle a eliminar los requisitos no deseados o innecesarios. [3]

Recuerde, cada persona considera el Problema o Necesidad desde su perspectiva particular. Usted debe entender estas diferentes perspectivas y reunir los distintos requisitos para construir un cuadro completo del Problema.

ii. Validar la información recopilada en las Entrevistas y/o Talleres

Para cada una de las Entrevista o Talleres generar una minuta con los puntos tratados con las Partes Interesadas y, una descripción del Problema según la visión del entrevistado o de los participantes del Taller.

Enviar el documento formalmente a cada entrevistado o participante del Taller, para la validación de la descripción del Problema o Necesidad. Según las prácticas de su organización podrá enviarse por mail, por escrito, requerir firma, enviar copia al Patrocinador, etc.

Análisis Situación as-is

i. Generar la Lista de Necesidades

Compilar una Lista de Necesidades detectadas en las distintas Entrevistas y Talleres, teniendo en cuenta que esta necesidad pude corresponder al problema completo, a un cuello de botella, a indefiniciones, a puntos de mejoras o carencias, para ello utilizar una tabla como la siguiente:

ii. Validar la Lista de Necesidades

Distribuir a todos los entrevistado y/o participantes de los Talleres la Lista de Necesidades y pedirles que:

• Validen si las necesidades identificadas corresponden o no con su punto de vista.
• Ajusten el Ranking de las Necesidades según el criterio de cada uno de los entrevistados.
• Incluyan comentarios si lo estiman pertinente.
• Devolver la copia con sus respectivas modificaciones.

iii. Generar la Definición del Problema

A partir de la Listas de Necesidades, devueltas por las Partes Interesadas, generar un ranking de Necesidades general y, considerando las Necesidades que ocupan los primeros lugares establecer una primera formulación del problema. A continuación generar la definición del problema usando un formato como el siguiente:

iv. Validar la Definición del Problema con el Negocio

La Validación de la Definición del Problema y la generación de la versión final se hará con la participación de la gente del Negocio y, utilizando el procedimiento acordado al momento de validar la lista de las Parte Interesadas a entrevistar.

Comentario

En general, el aplicar un método como el propuesto es considerado, en el mejor de los casos, como una actividad que no corresponde al tamaño de la empresa y, en otros casos, que es simplemente una pérdida de tiempo. No obstante, mi experiencia señala que todo tiempo que se ocupa en las definiciones, previas a la ejecución de un proyecto, tales como: Identificación del Problema, Definición del Alcance o Producto, Anteproyecto y Plan de Proyecto son inversiones en tiempo y recursos que redundarán en una mayor probabilidad de lograr un proyecto que cumpla con los objetivos y expectativas del Negocio.

Este artículo sobre el Anteproyecto cuenta con tres partes:

Parte 1:  La Identificación del Problema o Necesidad

Parte 2: Solución Esperada -Definición de Alcance – EAA

Parte 3: Análisis de Factibilidad de un Proyecto

Referencias

[1]

Fantasia de lo Nuevo

No inventemos la rueda cada vez que comenzamos un proyecto.
si bien no todo esta inventado bajo el sol , hay que dotarnos o dotar a nuestro grupo de un metodo para alcanzar objetivos.
Es Mas util si se trata de objetivos que se  repetiten
fabricar el mismo producto es un proceso repetitivo.
fabricar armarios  para ropa es un proceso repetitivo.
fabricar armarios  para ropa segun los requisitos de cada cliente es un proceso repetitivo?

Fabricar maquinas de soft es (abstrayendo) un proceso repetitivo.

    un proceso con pasos predeterminados (fases / etapas)
Lo que es muy cambiante son los objetivos o propositos (por lo tanto el contenido de "los pasos")
Entonces deberiamos apuntar a formalizar un marco para el proceso de desarrollo

estandarizar el proceos siguiendo algun modelo de "ciclo de desarrollo" 
Es decir , estructurar las actividades , identificar los costos y tener muy bien definidos los productos
Tramo de control , una estrada una salida  , grados de libertad , documentacion , metodo de costeo de los recursos , objetivos , metas , resultados . precedencia. informacion y dato , unidad , productividad

La recomendacion de manual es:bajo acoplamiento
En las pymes , cuando el personal es escaso , no pueden distribuir funciones y procesos.
Al contrario , se concentran lo mas posible haciendo a sus empleados polifuncionales.
Aun cuando la concentracion de procesos es un riesgo no solo por la rigidez resultante sino por la seguridad de la empresa , prima la cuestion del costo .
Muchas pymes para bajar costos , hacen parte del trabajo contable , control de  stock y administracion de compras y ventas "entrecasa" aun cuando no cuenten no cuente con personal capacitado.
Gralmente en estas empresas cuando se refieren a gestion o contabilidad , se refieren a lo que identifican como "TODO"
Hubo un modelo de los años 70 , cuya arquitectura todavia sobrevive en muchos soft en uso en la actualidad. La peor herencia de esos sistemas "legacy" fue las estructuras de datos utilizadas
La primera vez que tuve contacto con algo de eso fue en 1984 cuando el desarrollador de soft de un supermercado de Jujuy me mostro lo que estaba haciendo... El a la mañana trabajaba en una reparticion publica con una IBM sistema 34 y por la tarde trataba de meter la gestion del super en un par de disketes de 8" ! en una Pc IBM xt. Creo que lo hacia en cobol. Un programa monolitico monstruso con una cantidad impresionante de archivos. Lo que se veia muy bien era: la traslacion que habia hecho de los menues , a partir de lo que hacia la  vieja y enorme ibm sistema 36
Volvi a estar en contacto con algo asi un par de años despues trabajando para un distribuidor de Pc Bull , que habia recibido como parte del paquete a vender un sistema de gestion en un lenguaje propietario llamado BAL (Basic Administrative Lenguage). Era un sistema integrado de compras , ventas ,stocks , contabilidad (gral , iva) , sueldos.
Con el tiempo descubri que eral la traslacion a BAL de un sistema que daba vueltas por el pais , creado por no se quien , que originalmente estaba en BASIC ! compilado con un manejador de archivos algo como el Btrieve.
Años despues me lo volvi a encontrar encarnado en "Tango", seguia en basic compilado pero con una libreria sql
Ese programa   era  visto por los "contables" de las pymes como de altas capacidades y gran integracion.
Visto desde su arquitectura y codigo ... era una espantosa suma de codigo Spagheti , archivos oportunistas , mucho batch superado con dependencias forzadas y acoplamiento a todo gas!
Entonces ... la experiencia en las pymes dice que es efectivo un sistema altamente acoplado (eso que el vendedor llamara: "integrado") 

SISTEMA INTEGRADO PARA PYMES

La recomendación de manual es:bajo acoplamiento
En las pymes , cuando el personal es escaso , no pueden distribuir funciones y procesos.
Al contrario , se concentran lo mas posible haciendo a sus empleados polifuncionales.
Aun cuando la concentración de procesos es un riesgo no solo por la rigidez resultante sino por la seguridad de la empresa , prima la cuestión del costo .
Muchas pymes para bajar costos , hacen parte del trabajo contable , control de  stock y administración de compras y ventas "entre casa" aun cuando no cuenten no cuente con personal capacitado.
Gralmente en estas empresas cuando se refieren a gestión o contabilidad , se refieren a lo que identifican como "TODO"
Entonces ... la experiencia en las pymes dice que es efectivo para una estructura administrativa de una pyme pequeña o mediana , un sistema altamente acoplado (eso que el vendedor llamara: "integrado")
Con un un poco de trabajo , lo que resulta de acoplar diversos sistemas es mantenible ... y sobre todo tiene suficientes grados de libertad como para no tener rigidez de muerte.
Aproveche para replantear conceptos y estructuras y así presentamos nuestro primer sistema altamente integrado para la administración de stocks , cuentas , ivas, ventas , compras y cobranzas
Un sistema que registra y propaga inmediatamente las transacciones generadas o registradas. Haciendo posible que hasta una unica persona sea capaz de mantener actualizado todo el sistema y accesos de consultas en red.

La primer encarnacion fue en una distribuidora de articulos no medicinales para farmacias y sanatorios

Garantias y responsabilidades en Epaña , vistopor los clientes

3.6.2. Distincion entre garantías y responsabilidades

Ambas figuras –garantía y responsabilidad– se solapan parcialmente y resultan algo difíciles de distinguir. Mejor dicho, podemos afirmar que las
“responsabilidades” son una de las consecuencias a las que puede dar lugar la infracción de una garantía.
Garantías
Denominamos garantías a los compromisos u obligaciones que el proveedor-licenciante asume a favor del usuario respecto a las condiciones (características,
prestaciones, buen funcionamiento) que debe cumplir el software objeto de la licencia.
De este modo, si el software no cumple o deja de cumplir en algún momento dichas condiciones, el proveedor-licenciante está obligado a emprender las
actuaciones oportunas para que el software se ajuste a las mismas.
En particular, cabe destacar la garantía de buen funcionamiento, en virtud de la cual el proveedor debe asegurar al usuario-licenciatario que el software funcionará
correctamente durante el plazo de vigencia de la licencia –o, al menos, durante un tiempo determinado– de modo que, en caso de que el software presente algún
fallo, prestará la asistencia oportuna al usuario para remediarlo.
A todo software se le atribuyen unas características y prestaciones determinadas en función del tipo de software de que se trate; así como de aquellas características
especiales que el proveedor haya incluido en la licencia (o bien en la documentación accesoria, envoltorios, folleto, publicidad, etc.). Además, se entiende que el
software estará siempre listo para funcionar correctamente, cuando el usuario decida ejecutarlo correctamente. De lo contrario, estaremos ante una incidencia debida
a un fallo de funcionamiento o bien el software presentará un defecto.
Las licencias de uso regulan qué garantías debe prestar el proveedor, el modo de prestarlas y el plazo (durante cuánto tiempo, a partir del inicio de la licencia). Es
decir, en el caso de que ocurriera alguna de las incidencias descritas, el proveedor-licenciante asistirá o no al usuario para poner fin a la incidencia y, en su caso,
como le asistirá.
El modo de poner fin a la incidencia será mediante:
Reparación del fallo o defecto
Sustitución de la copia por otra
Resolución o cancelación de la licencia: El proveedor devuelve el precio al usuario y devolviendo éste la copia del software al proveedor.
En principio, el usuario sólo podrá acudir a la resolución de la licencia como último recurso, cuando no sea posible la reparación del defecto o sustitución de la
copia.
En cualquier caso, las cláusulas de las licencias que estipulen las garantías –así como sus posibles limitaciones o exoneraciones– deberán respetar una serie de
normas legales imperativas que, en cada país, obligan a prestar unas garantías mínimas sobre el software.
Creemos conveniente explicar de manera sencilla las clases y origen legal de las garantías. En derecho continental, como en España, las clases y categorías jurídicas
de las garantías son distintas respecto de las propias del derecho anglosajón. Sin embargo, muchas licencias de software, aun escritas en castellano y para regir en
España, hacen referencia a las garantías típicas del derecho anglosajón. Esto hace que la redacción de dichas cláusulas nos parezca poco clara y confusa, incluso para
los propios juristas.
El contenido y alcance de las garantías es similar en ambos casos, así como las acciones que se estipulan a favor del usuario para hacerlas efectivas: reparación,
sustitución de la copia o devolución del precio con cancelación de la licencia.
Conforme al derecho español, las garantías sobre el software serían las siguientes:
La garantía de saneamiento frente a defectos ocultos, por aplicación analógica de las normas que regulan la compraventa (Código civil y Código de
Comercio): el licenciatario podrá reclamar –en el plazo de los 6 meses siguientes al inicio de la licencia– que se le devuelva el dinero y se cancele la licencia,
o bien que el proveedor le rebaje el precio abonado. Esta garantía será aplicable, por analogía, a muchas de las licencias, en particular las del software
comercializado en masa a consumidores.
Los Tribunales vienen aplicando a las licencias de uso, por analogía, la garantía de saneamiento frente a defectos ocultos. Aun en el caso que una licencia de uso, por
sus circunstancias específicas sea asimilable, no a una compraventa, sino a un arrendamiento de cosa, de obra o prestación de servicio (por ejemplo, por concederse
para un plazo determinado; por obligarse el proveedor a adaptar el software a necesidades particulares del usuario, a realizar tareas de instalación, etc.), se entienden
que rigen garantías similares:
Deber del proveedor de mantener al usuario en el uso normal y pacífico del objeto contractual (garantía propia en el arrendamiento de cosas).
Deber de mantener el resultado final en las condiciones pactadas (garantía propia en el arriendo de obra).
Deber de prestar el servicio con la diligencia propia de un profesional en la materia (garantía propia de la prestación de servicios).
El incumplimiento de estas garantías da lugar a que, en este caso el usuario, pueda pedir igualmente la reparación del defecto, sustitución de la copia o resolución de
la licencia (devolviéndose las partes, respectivamente, la copia del software y el precio abonado).
La garantía de buen funcionamiento del software, por aplicación de la normativa sobre garantías en la Ley General de Defensa de los Consumidores y
Usuarios (art. 11).
En el plazo mínimo de 6 meses, el licenciatario podrá reclamar frente al proveedor, en caso de error, defecto o falta de las condiciones óptimas para cumplir el uso a
que esté destinado el software. El proveedor estará obligado a reparar el error (debiendo de tener un servicio técnico adecuado para ello) y, si la reparación no es
posible o satisfactoria, deberá sustituir la copia del software por otra o devolver el precio pagado al licenciatario.
16/7/2019 3.6.2. Distincion entre garantías y responsabilidades | Gestiweb: Eneboo ERP software libre - Diseño y desarrollo web - Tiendas on-…
https://www.gestiweb.com/?q=content/362-distincion-entre-garantí-y-responsabilidades 2/7
‹ 3.6.1. Consideraciones generales up 3.6.3

Garantias y Responsabilidades 

Extraido de: www.todaviasomospocos.com

2.2.2 “Entregables” o servicios específicamente delimitados en relación al software.

– Contra el pago final de los Servicios, el Cliente obtendrá una licencia perpetua, no
exclusiva e intransferible, para propósito de su negocio interno, para utilizar, copiar, modificar y
preparar trabajos derivados de los Entregables que sean desarrollados en el transcurso de los
Servicios, debiendo cumplir con cualquier restricción de cualquier material de un tercero
contenido en los Entregables. La Empresa retendrá todo otro derecho de propiedad intelectual
sobre los Entregables. Sujeto al cumplimiento de las obligaciones de confidencialidad, cada
parte podrá usar los conceptos, técnicas y know-how utilizados y desarrollados durante la
prestación de los Servicios. En cualquier caso, la Empresa no tendrá restricción alguna en
desarrollar, para sí misma o para otros, materiales que puedan entrar en competencia con los
Entregables, independientemente de su semejanza con los Entregables. Asimismo, la
Empresa podrá usar con entera libertad sus conocimientos, habilidades, experiencia y
cualquier idea, concepto, conocimientos técnicos (know-how) y técnicas que hayan sido
usados en el curso de la prestación de los Servicios. Durante la prestación, la Empresa podrá
utilizar productos, materiales, herramientas y metodologías que sean propiedad de la Empresa
o de terceros licenciantes de la Empresa (conjunta y convencionalmente, el “Capital de
Conocimientos de la Empresa”). El Cliente no tendrá ni obtendrá derechos sobre el Capital de
Conocimientos de la Empresa (o cualquier modificación o mejoras al mismo), distintos a: (i) el
uso del Capital de Conocimientos de la Empresa según sea periódicamente autorizado por
escrito por la Empresa, únicamente para los fines de cumplir con las responsabilidades del
Cliente; (ii) en la medida en que el Capital de Conocimientos de la Empresa sea incorporado a
un Entregable, su uso como parte del Entregable, únicamente para fines internos del negocio
del Cliente; o (iii) de conformidad con los términos de las licencias estándares de la Empresa
respecto de dicho Capital de Conocimientos de la Empresa o, en el caso de tratarse de Capital
de Conocimientos de la Empresa de propiedad de terceros, conforme a los términos
aceptables para el tercero que corresponda. Si cualquier Capital de Conocimientos de la
16/7/2019 Contratos de Software y Consultoría Profesional en la República Argentina | Todavía Somos Pocos
www.todaviasomospocos.com/aportes/contratos-de-software-y-consultoria-profesional-en-la-republica-argentina/ 8/24
Empresa es puesto a disposición del Cliente bajo el apartado (i) que antecede, dicha puesta a
disposición se considerará bajo la modalidad “as-is” (“en la condición en que se encuentra”) y
sin garantía alguna, expresa o implícita, de ningún tipo y cualquier Capital de Conocimientos
de la Empresa puesto a disposición conforme al apartado (iii) precedente estará sujeto,
únicamente, a los términos de la licencia aplicable. Entre el Cliente y la Empresa el Capital de
Conocimientos de la Empresa será considerado como Información Confidencial de la
Empresa.
– La Empresa otorga al Cliente una licencia no exclusiva, intransferible, no asignable y
gratuita para utilizar el Producto de Trabajo mientras que el Cliente mantenga la licencia del
Software con el que opera el Producto de Trabajo. La Empresa no está obligada a
proporcionar soporte o mantenimiento continuo para cualquier Producto de Trabajo. La
Empresa conservará la titularidad del Producto de Trabajo y cualquier técnica, oficio, concepto
o conocimiento técnico (know-how) que se utilicen o desarrollen durante la prestación de los
Servicios. Los sistemas prototipo y los programas de muestra proporcionados por la Empresa
están diseñados para ayudar al Cliente a aprender a usar el Software y para efectos de
demostración; no están diseñados para ser usados con propósitos de producción sin antes no
fuesen efectuadas las pruebas adecuadas.

2.3 Límite de Responsabilidad y Garantías.
16/7/2019 Contratos de Software y Consultoría Profesional en la República Argentina | Todavía Somos Pocos
www.todaviasomospocos.com/aportes/contratos-de-software-y-consultoria-profesional-en-la-republica-argentina/ 9/24
Continuando un poco con el análisis que comenzamos en el punto anterior “in-fine”, este tipo
de contratos se caracterizan por tener tecnicismos y especificaciones tan propias de la materia
que muchas veces es difícil, en la práctica, detectar un incumplimiento contractual a menos
que sea muy grosero; y es justamente por esta falta de absolutos y de unificación de criterios
que entre las partes son habituales los intercambios de opiniones sobre imputación de
responsabilidades. Siguiendo la lógica del razonamiento anterior, es que el licenciante suele
formular declaraciones de garantía y cláusulas limitantes de responsabilidad, que velan por la
ecuación económica tenida en miras al otorgar la licencia, limitando las indemnizaciones por
casi todo concepto al monto/honorario establecido como contraprestación del licenciamiento
de uso.

A continuación redactaré algunas de las cláusulas mayormente utilizadas,  para limitar responsabilidad:

– En este acto la Empresa y sus licenciantes expresamente renuncian a todas las
garantías, condiciones y declaraciones no mencionadas, expresa o implícita, sin límite,
incluyendo cualquier garantía de obtención de un resultado o de aptitud del software para un
propósito particular. La empresa y sus licenciantes no garantizan ni declaran que el software
cumplirá, acatará o estará en conformidad con las leyes, reglamentos, requerimientos o
lineamientos de cualquier entidad gubernamental creadas y/o ha crearse. Tanto la Empresa
como sus licenciantes proporcionan su software “en el estado en que se encuentra” (“as is”).
La Empresa y sus licenciantes no serán responsables por ningún perjuicio incidental o
indirecto, resultante del uso incorrecto o de la inhabilidad para el uso del software por parte del
Cliente y/o persona autorizada por él. La Empresa y sus licenciantes tampoco serán
responsables por los hechos, actos u omisiones de terceros a los que eventualmente el cliente
encomendare la instalación u operación del software. La responsabilidad de la Empresa frente
al Cliente y a cualquier otro tercero con relación al cumplimiento o incumplimiento de sus
obligaciones, y con cualquier otro asunto relacionado con los servicios y con las licencias, sea
de fuente contractual, extracontractual o legal, no excederá, en su conjunto, los honorarios
efectivamente abonados por el Cliente a la Empresa en contraprestación por los servicios o
licencias objeto del reclamo. En ningún caso la Empresa será responsable por gastos,
pérdidas o daños indirectos o mediatos, lucro cesante, daño moral, pérdida de chance, ni
daños punitivos, entre otros. La limitación de responsabilidad de la Empresa establecida
precedentemente representa el acuerdo total de las partes en la materia y, en tal sentido, la
contraprestación de la Empresa contempla dicha limitación de responsabilidad. Las partes
convienen en que en caso de tener créditos por cobrar contra la otra, dirigirán sus acciones
sólo contra los activos de la parte deudora y en ningún caso accionarán en contra de los
accionistas, socios, directores o propietarios de la otra parte. Ni el Cliente, ni la Empresa o sus
Licenciantes serán responsables por daños indirectos, aunque hayan sido o no previstos y/o
informados. Los licenciantes de la Empresa no serán responsables por los daños directos y
renuncian a cualquier responsabilidad relacionada con el uso del software.
– La responsabilidad de la Empresa frente al Cliente y a cualquier tercero con relación al
cumplimiento o incumplimiento de sus obligaciones y con cualquier otro asunto relacionado
con los Servicios y con los Entregables, sea de fuente contractual, extracontractual o legal, no
excederá, en su conjunto, los honorarios efectivamente abonados por el Cliente a la Empresa
en contraprestación por los Servicios o Entregables objeto del reclamo. Sujeto al límite
establecido precedentemente, la Empresa sólo responderá de los perjuicios directos
previsibles que constituyan daño emergente. En ningún caso la Empresa será responsable por
gastos, pérdidas o daños indirectos o mediatos, lucro cesante, daño moral ni daños punitivos.
La Empresa no será responsable de los retrasos, incumplimientos o por cualquier otro hecho o
acto no imputable a la Empresa.

16/7/2019 Contratos de Software y Consultoría Profesional en la República Argentina | Todavía Somos Pocos
www.todaviasomospocos.com/aportes/contratos-de-software-y-consultoria-profesional-en-la-republica-argentina/ 10/24