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

MANEJO DE SOLICITUDES DE CLIENTES

Para decidir esto se reviso los estándares  ISO , ITIL , IEEE

La semántica es confusa , pero trate de generar un diccionario unificado y efectivo para el trabajo diario de atención al cliente 

Una solicitud De un CLIENTE  puede ser que ….:
★★CLASIFICAR SOLICITUD

      ★★PIDA UNA CORRECCIÓN de lo que experimenta como una FALLA

1.1)      Es un incidente

1.2)     Es un Problema

         ★★PIDA UNA MEJORA

2-1)  Es una adaptación        

              Funcional

              No funcional

2-2) Es un Perfeccionamiento

              Funcional

              No funcional  

        ★★INFORMA DE UNA DISCONFORMIDAD

                    Funcional

                    No funcional

      ★★PIDA UN SERVICIO

Cada Solicitud , deberá:

OREGISTRAR

OCLASIFICAR

OACEPTAR

ORESOLVER  

Una falla es:

La manifestación de un defecto (incidente/problema//disconformidad)

Un incidente es :

 un suceso no deseado , que se manifiesta con mensajes de error , detención del sistema , resultados inadecuados 

Un problema es: 

 un suceso no deseado difícil de identificar , no es la cima de un árbol de fallas  un suceso intermedio en el árbol de fallos, causa de varios sucesos no deseados posteriores
Una adaptacion es:
Un Perfeccionamiento es:

Una disconformidad es:

 Las disconformidades aparecen simplemente porque el comportamiento esperado del sistema no coincide con el comportamiento actual. Esto puede ser el resultado de un defecto del software, pero puede ser fácilmente el resultado de un desconocimiento de las capacidades del sistema, o de la utilización incorrecta del flujo de trabajo, o de una documentación pobre, o de cambios en las directrices de la empresa, o de otras tantas razones.

Son objetivos que no se alcanzan

Son objetivos que no están alcanzados satisfactoriamente

Son objetivos nuevos

Un Servicio es:

una solicitud de intervención 

Un grafico ayuda como 100 palabras

ESPECIFICACIONES UTILES

(porque inservibles tambien hay y solo generan entropia y confusion)

Las especificaciones deben tener un montón de características 

Una de las que me parece mas importante es : QUE SEA COMPROBABLE
Porque como ya hemos visto , la corrección de un soft debe ser verificado contra las especificaciones
Una especificación puede ser una reformulacion de un requisito que se ha elegido como una restricción , o una formulación de una característica funcional o no que se ha seleccionado
entonces.... son decisiones documentadas
El standard de la ieee dice algo al respecto
(un standard es una decisión tomada y que puede incorporarse como un requisito)

IEEE-STD-830-1998 : ESPECIFICACIONES DE LOS REQUISITOS DEL
SOFTWARE
2.3.6 Comprobable
Un SRS es comprobable si, y sólo si, cada requisito declarado es comprobable. Un
requisito es comprobable si, y sólo si, allí existe algún proceso rentable finito con que
una persona o la máquina puede verificar que el producto del software reúne el
requisito. En general cualquier requisito ambiguo no es comprobable.
Los requisitos de No-verificable incluyen las declaraciones como "trabaja bien",
"interface humana buena" y "normalmente pasará" no pueden verificarse los requisitos
de esos porque es imposible de definir las condiciones "bueno," "bien" o
"normalmente". La declaración que "el programa nunca entrará en una vuelta infinita"
es el no-verificable porque la comprobación de esta calidad es teóricamente imposible.
Un ejemplo de una declaración comprobable es:
El rendimiento del programa se producirá dentro de 20 seg de evento 60% del tiempo;
y se producirá dentro de 30 seg de evento 100% del tiempo.
Esta declaración puede verificarse porque usa condiciones concretas y las cantidades
mensurables.
Si un método no puede inventarse para determinar si el software reúne un requisito
particular, entonces ese requisito debe quitarse o debe revisarse.