DSN_XP y la plataforma transaccional de pago

Payphone

https://www.payphone.app/terms/

DSN_XP entra en contacto con esta plataforma por referencia explícita de Terapia de Negocios, un grupo de profesionales a cargo de impulsar a emprendimientos desde su cobertura técnica como plataforma.

Digital Web

Dentro de un proceso de transformación como consecuencia del impacto de la COVID19, DESSINE debe reinventarse en su proceso de enfoque de su flujo principal de esfuerzos y la forma en la cual comercializamos este esfuerzo.

Parte de este proceso nos llevó a analizar la forma en la cual se puede montar una tienda virtual y con ello formar parte de la demanda por servicios digitalizados en especial para transacciones comerciales y en este mismo contexto es que esta entrada nos permite tener registros de nuestro estudio de esta plataforma para futuras consultas de referencia.

Otro aspecto que nos empujó de lleno a jugar con este tipo de tecnología fue la necesidad urgente de aplicar nuestro protocolo de negociación con terceros lo que nos permite establecer entornos de respeto para nosotros desde y para con terceros, en especial para con los clientes de DESSINE

El Cliente acepta que toda transacción en la aplicación conlleva el pleno entendimiento de este documento y que acepta los costes involucrados en el uso del mismo, conforme se especifica más adelante, así como todos los beneficios que este conlleva.

Mobile

Para utilizar la aplicación PayPhone, el Cliente se ha registrado e identificado mediante el ingreso de su usuario y contraseña u otro mecanismo de autenticación aceptado por software de propósito específico del fabricante del dispositivo móvil del Usuario, los cuales deben mantenerse en todo momento bajo su confidencialidad y seguridad, y a través de los cuales se autentica por tanto su acceso, vinculando unívocamente con su titular, así como las transacciones realizadas en la aplicación, como expresión libre de su voluntad. PayPhone no es responsable por la revelación, pérdida o sustracción relacionadas con el uso no autorizado de los mismos.

Al hacer clic en “Aceptar”, el Cliente declara haber leído, entendido, aceptado con plena voluntad el presente instrumento en todas sus partes; por lo cual, garantiza que la información y datos registrados durante el proceso de verificación y autenticación son verídicos y lícitos, eximiendo de responsabilidad a PayPhone sobre la misma.

Servicios

Payphone oferta como servicio la gestión de procesamiento de cobros o pagos mediante una aplicación tecnológica para interconectar con otros usuarios de la aplicación.

El Cliente acepta y reconoce que el pago realizado con Payphone no garantiza contraprestación alguna y/o entrega del bien al que haya lugar. En tal virtud, toda transacción que se gestione entre dos o más partes con utilización de la aplicación PayPhone, se lleva a cabo en la plataforma en calidad de tercero independiente, lo cual deslinda a PayPhone de cualquier relación con el/los Clientes y sus pares o proveedores de servicios y bienes.

Como proveedor, DESSINE no oferta bienes, nuestro producto comercial se denomina BANDA DE TIEMPO y en concepto es un servicio acordado de antemano con nuestros clientes a través de nuestra propuesta comercial INCEPTION en la cual exponemos nuestro modelo de negocio y la necesidad de un pago por adelantado para la liberación del servicio.

Plataforma de pago

El uso de la aplicación PayPhone integra otros servicios prestados por terceros, bajo su responsabilidad, como es el caso el de Externalización de Servicios S.A. EXSERSA, compañía de servicios transaccionales, debidamente calificada para operar como tal, por medio de los cuales, el Cliente en función del saldo en el balance registrado en la aplicación, decide el uso del mismo, ya sea, para un pago o retiro de dichos fondos, según su conveniencia.

Este punto es importante ya que detrás del escenario de una transacción electrónica, las responsabilidades de todos los estados de la transacción deben ser asumidos en su mayoría por quien presta el servicio como plataforma de pago.

Por medio del presente, el Cliente declara que el destino y origen de los fondos que consten o se utilicen por medio de la aplicación son de carácter lícito y cumplen con la normativa ecuatoriana. Toda la responsabilidad de pago hacia el banco emisor de cualquier tarjeta de crédito o débito registrada, es total responsabilidad del usuario, lo cual deslinda totalmente a PayPhone del correcto uso de los cupos asignados.

Inicialmente, DESSINE en su protocolo comercial considera el uso de tarjetas de crédito para transacciones comerciales como un tema delicado que está asociado a la normativa legal vigente sobre la manipulación y custodia de datos altamente personalizados de los clientes por lo que posterga para casos muy especiales el pago mediante la forma de tarjeta de crédito / débito.

Dispositivos transaccionales

Se entiende que estamos ante un escenario MOBILE y como se resalta al principio de esta entrada, las transacciones comerciales se realizan mediante el uso de una aplicación instalada en un dispositivo MOBILE.

El uso del dispositivo que el Cliente registre para gestionar los pagos o cobros con la Aplicación, es de su completa responsabilidad, así como el cambio del mismo, de ser el caso.

Aspectos tarifarios

Este aspecto debe ir mejorando conforme se ejecutan transacciones a nuestro favor y las diferentes tarifas que aplican por el uso de la plataforma de transacciones de cobro/pago.

El Cliente mediante este instrumento, reconoce y acepta las tarifas que aplican por el uso de la aplicación, conforme se detalla a continuación:
Hasta 6% de Comisión por monto retirado y/o cash out de dinero en la app a su cuenta corriente o de ahorros de su banco elegido (“Comisión”)
Payphone entregará al usuario el total del monto retirado o cash out; menos:
(i) La Comisión, en este caso cobrada por Externalización de Servicios S.A. EXSERSA, conforme lo establecido en la Sección 1 de este instrumento.

Tratamiento de los datos

Toda información registrada con fines de uso y acceso a los productos y servicios a través del aplicativo PayPhone, está sujeta a privacidad, conforme lo señala la normativa legal vigente aplicable. Sin embargo, el Cliente es responsable de la custodia de claves, contraseñas, usuarios, así como de contar con las seguridades al hardware que soporta el canal a través del cual accede.

PayPhone podrá tratar los datos de carácter personal del Cliente, incluidos los patrones de seguridad antes descritos, con las siguientes finalidades:

identificar al Cliente en esta aplicación y/o servicios a distancia por medios de comunicación electrónica implementados por PayPhone;
validar y verificar sus datos cuando el Cliente acceda desde otras aplicaciones, dispositivos móviles, canales digitales y/o servicios a distancia por medios de comunicación electrónica implementados por PayPhone;
dar cumplimiento al objeto de la Aplicación;
aplicar las medidas necesarias para el cumplimiento de lo establecido en las normas legales vigentes para prevenir, detectar y erradicar el delito de lavado de activos y financiamiento de delitos incluido el terrorismo, así como informar a las Autoridades Competentes incluyendo aquellas que por las leyes o reglamentariamente facultadas requiera información de tipo crediticio u otro aplicable;
realizar análisis estadísticos (analítica) sobre el uso de esta aplicación y/o de servicios a distancia dispuestos por PayPhone y que comprenden todo tipo de canales, medios de comunicación electrónica, a través de redes telemáticas, con el propósito de ampliar los servicios;
aplicar seguridad en el uso de canales o aplicaciones de PayPhone y/o en productos y servicios a través de estos medios, analizando posibles fraudes o suplantaciones de su identidad. La conservación de datos, patrones y otros implementados a futuro, recabados por PayPhone permanecerán durante el plazo previsto en la norma legal vigente aplicable.

Aceptación

Por tanto, y mediante el presente Acuerdo, el Cliente acepta y declara en forma expresa:

Que, toda la información proporcionada a PayPhone es verdadera y precisa;
Que, se ha informado en forma previa, ha leído y aceptado las condiciones, incluyendo las tarifas y comisiones que aplican. Cualquier modificación será notificada en forma electrónica con 30 días de anticipación y su utilización implicará aceptación por parte del Cliente;
Que, está a existencia de obligaciones con PayPhone una vez aceptados los términos y condiciones respectivos;
PayPhone podrá demandar el incumplimiento de obligaciones contraídas por parte del Cliente a través del aplicativo, bastando para ello la presentación del presente Instrumento, cuyo perfeccionamiento es electrónico y constituye prueba plena para el proceso judicial que se plantee, con reconocimiento formal y expreso por parte del Cliente de la existencia de la obligación de dar, hacer o no hacer, conforme lo establecido en el presente.

DSN_XP y una arquitectura basada en valor

VDAM

Marco de trabajo VDM basado en VDML y el diseño ontológico

Joachim METZGER et. al.

BMW Group, Electrics/Electronics and Driving Experience Environment

Munich, 80788, Germany

Modelado en base al valor

La complejidad y la incertidumbre han evolucionado como importantes desafíos para el espíritu empresarial en muchas industrias.

Value Delivery Architecture Modeling (VDAM) es una propuesta para un nuevo enfoque para el modelado de negocios para superar estos desafíos.

Además de la creación de transparencia y claridad, nuestro enfoque apoya la operacionalización de ideas de modelos de negocio.

VDAM se basa en la combinación de un nuevo lenguaje de modelado empresarial llamado VDML, construcción de ontologías y la implementación de un nivel de abstracción entre empresas.

La aplicación de nuestro nuevo enfoque en el área de la movilidad eléctrica en Alemania, un sector industrial con altos niveles de incertidumbre y falta de común comprensión, muestra varios resultados prometedores.

VDAM permite el desarrollo de una visión inequívoca e imparcial sobre la creación de valor. Además, permite varias aplicaciones líderes para una decisión más informada hacia la implementación de nuevos modelos de negocio.

Introducción

Un elemento clave de la investigación en el campo del emprendimiento es la cuestión de cómo describir y desarrollar modelos de negocio. Sin embargo, todavía hay una variedad de definiciones y entendimientos entre los investigadores de lo que es o debería ser un Modelo de Negocio [2, 6, 9, 21].

La complejidad y la incertidumbre son algunos de los mayores desafíos para el emprendimiento en un mundo complejo e interrelacionado, siendo relevante para la mayoría de las industrias.

A menudo, la creación de valor ya no es un proceso directo, pero el valor debe ser creado en redes complejas.

Entre otras cosas, la complejidad y la incertidumbre provocan una brecha entre la estrategia y los procesos de negocio, como muestran Al-Debei y Avison para el negocio digital. Por tanto, los modelos de negocio deben considerarse como una capa intermedia que conecta la estrategia con los procesos comerciales [1].

Muchos de los lenguajes de modelado de negocios más conocidos tienden a centrarse en los aspectos estratégicos de los modelos de negocio. Esto se mantiene incluso para los lenguajes sugeridos por investigadores que están de acuerdo con el papel intermediario de los modelos comerciales [15].

Estos enfoques son apropiados para el desarrollo y la innovación del modelo de negocio por tomar puntos de vista estratégicos y utilizar solo algunos elementos para su descripción. Sin embargo, la creación de valor colaborativa o complejos entornos de mercado, incluido el mapeo de estos últimos, no son necesariamente incluidos o destinados a ser descritos con estos enfoques. Además, estos lenguajes no incluyen herramientas para apoyar la operacionalización de modelos comerciales [1, 8, 16].

No obstante, consideramos necesario para estimular el éxito a ambos, el compromiso empresarial en la globalización y la complejidad del mundo de hoy.

El alcance de este documento es presentar una propuesta para un nuevo enfoque para el modelado de negocios, combinando la entrega de valor el modelado del lenguaje y las ontologías con una visión abstracta de creación de valor en los mercados que permite la representación y reducción de la complejidad, creación de transparencia así como el soporte para la operacionalización de modelos de negocio. Llamamos a esto el enfoque Modelado de Arquitectura de Entrega de Valor (VDAM)

Antecedentes teóricos

La ciencia del diseño produce cuatro tipos de artefactos, a saber:

construcciones,
modelos,
métodos e
instancias [10],

Y se originó en la ingeniería y las ciencias de lo artificial [19]. Elegimos seguir un enfoque de ciencia del diseño con el objetivo de desarrollar un artefacto innovador y con propósito - VDAM - que conquista los desafíos del modelado de negocios en entornos complejos e inciertos y apoya su operacionalización.

Durante todos los pasos del proceso, cumplimos con la investigación marco y directrices para la ciencia del diseño introducidos por Hevner et al., que se basan en el principio de que el conocimiento y la comprensión se derivan de la construcción, la aplicación y evaluación de un artefacto [7]

Para alcanzar nuestro objetivo de crear transparencia y claridad, además de incluir métodos de apoyo a la operacionalización en un enfoque integrado de modelado de negocios, basamos nuestra propuesta de enfoque sobre dos artefactos existentes: Lenguaje de modelado de entrega de valor (VDML) [12, 13] y Modelado de ontologías en los negocios [14].

Modelos de negocios como intermediarios y ejemplos de UML

VDML fue lanzado por primera vez en una versión beta por el OMG en abril de 2014 [12]. Actuando como un intermediario entre la estrategia y los procesos de negocio, VDML ofrece respuestas a los desafíos en el modelado empresarial actual (ver figura 1). Por tanto, VDML es un lenguaje muy adecuado para nuestro objetivo de crear un enfoque de apoyo a la operacionalización para el modelado de negocios. VDML tiene sus orígenes en los sistemas de información (IS) y es un enfoque especificado por UML para el modelado de negocios.

Proporcionando un lenguaje de modelado estándar, VDML permite el modelado de la creación de valor, así como el intercambio de valor en un nivel estratégico. Además, VDML fue desarrollado para vincular

estrategia y modelos de negocio para actividades, roles, capacidades necesarias para dirigir una empresa. Por lo tanto, proporciona un lenguaje para el análisis y diseño de modelos de negocio de forma más operativa. VDML incorpora varios tipos de diagramas incluidos en las siguientes vistas:

Vista de red empresarial
Vista de red de actividad
Vista de responsabilidad de la organización
Vista de contribución de valor.

Además, VDML admite varios negocios existentes. Enfoques de modelado y análisis de negocios como Business Model Canvas o Value Networks [12, 13]. Ya en versiones pre-beta, los desarrolladores de VDML mostraron cómo el lenguaje puede utilizarse con éxito para la innovación del modelo de negocio. Esto incluye aplicaciones para servicios, procesos y negocios abiertos y modelos de innovación. Estas aplicaciones se centran en los tradicionales enfoques y concentrándose en empresas individuales y sus socios inmediatos [3, 4, 5, 18]

Además de utilizar un lenguaje de apoyo a la operacionalización, consideramos necesario generar transparencia, claridad y entendimiento común dentro y entre las partes interesadas y organizaciones, especialmente en la actualidad, a menudo la compleja creación de valor distribuido. Por lo tanto, combinamos el uso de diagramas VDML para la visualización de la creación de valor y el intercambio con el concepto de ontologías semiformales.

Las ontologías, originadas en la filosofía, hoy están en uso generalizado en el área de (SI) como especificaciones explícitas de conceptualizaciones.

Las ontologías tienen como objetivo crear una comprensión en un campo para resolver problemas o compartir conocimientos.

Por lo tanto, el enfoque principal es una mejor comunicación entre personas, organizaciones y máquinas que conducen a una mejor interoperabilidad entre y un mejorado desarrollo de sistemas. Al diseñar una ontología, es fundamental cumplir con las siguientes tres pautas:

Claridad, en el sentido de ambigüedad minimizada.
Coherencia, en el sentido de una consistencia interna.
Extensibilidad de la ontología diseñada [20].

De acuerdo con el enfoque de Uschold & Grunninger de construcción de ontologías, incluidos los pasos de captura, codificación, evaluación y documentación, Osterwalder transfirió el concepto de ontología desde (SI) hasta el modelado de negocios. El desarrollo de una ontología semiformal, simplemente llamada Business Model Ontology, ha sido la base del conocido enfoque Business Model Canvas [14, 15, 16].

Desde entonces otros investigadores [por ejemplo, 1] recogieron este concepto de ontología y hoy en día es un elemento predominante en el Modelado de Negocios.

Modelado de la arquitectura de entrega de valor

Para conquistar desafíos de complejidad, valor colaborativo, creación y falta de operatividad en el modelado de negocios, proponemos un enfoque al que nos referimos como Modelado de Arquitectura de entrega de valor. Basándonos en información sobre el mercado, crear una comprensión inequívoca de la creación de valor y oportunidades comerciales mediante la combinación de un subconjunto de elementos VDML y vistas con el desarrollo de una ontología semiformal.

Por lo tanto, el diseño de estas diferentes vistas y la definición en una ontología es un proceso iterativo. Esto permite una serie de aplicaciones para innovar o crear modelos de negocio. Permitiendo el análisis y desarrollo más profundos, VDAM es adecuado para un análisis inicial más estratégico de los modelos de negocio y para apoyar la operacionalización de modelos de negocios (ver Figura 2)

La clave de nuestro enfoque es la implementación de un nivel adicional de abstracción entre empresas, inicialmente dejando empresas específicas y sus modelos de negocio detrás mientras se centran en Roles abstractos, propuestas de valor y otros elementos. Esta abstracción proporciona una visión imparcial de cómo se crea el valor en situaciones de mercado complejas e inciertas, sentando las bases para llevar a cabo la innovación del modelo de negocio o la creación del modelo de negocio.

A continuación presentamos los conceptos e ideas clave de VDAM al describir el desarrollo de la vista más estratégica de nuestro enfoque. Otras vistas integradas en VDAM no se explican con tanto detalle.

El análisis de mercado se puede realizar de diversas formas desde esfuerzos complejos de inteligencia empresarial hasta entrevistas con expertos. Usando esta información, el primer y más estratégico tipo de

diagrama en nuestro enfoque está siendo diseñado, utilizando el llamado Diagrama de intercambio de propuesta de valor de VDML. Este tipo de el diagrama consta de tres tipos de elementos:

Roles (R),
Proposiciones de valor (VP) y
Conectores (C) (ver Figura 3). Aquí,

Los roles se definen como elementos abstractos que describen patrones de comportamiento o capacidades. Las propuestas de valor representan tangibles y valores intangibles de los entregables. Los conectores representan la asociación que conecta un rol con una propuesta de valor o una propuesta de valor con un rol [12, 13]. Una propuesta de valor en el diagrama de intercambio se puede describir como una tupla de 3 (R, VP, C), dónde:

R es un conjunto finito de roles.
VP es un conjunto finito de propuestas de valor.
R y VP son inconexos.
C: (R x VP) ∪ (VP x R) → ℕ es un conjunto múltiple de arcos

Como resultado, solo se puede ofrecer una propuesta de valor específica de un Rol a otro Rol. Además, dado que Roles y las propuestas de valor no deben ser idénticas, definimos que Roles y las propuestas de valor no pueden tener los mismos nombres. Siguiendo este enfoque, el intercambio de propuesta de valor resultante el diagrama visualiza y describe la creación de valor en un mercado desde una perspectiva más estratégica. Debido al uso de resumen se crea una vista imparcial de roles.

Una representación gráfica facilita la comprensión general de las interrelaciones entre Roles y su correspondiente Valor Proposicional. Sin embargo, para crear un inequívoco entendimiento entre todas las partes involucradas, la descripción dentro de una ontología es necesaria.

La información que se muestra en la ontología se basa en los requisitos de los elementos VDML utilizado en nuestro enfoque. Por tanto, además de los elementos Rol y propuesta de valor que forman parte de la propuesta de valor en el diagrama de intercambio, los elementos adicionales como capacidad, actividad o Valor deben incluirse en la ontología. Estos elementos son necesarios para el diseño más detallado y con ello vistas de apoyo a la operacionalización.

Para la descripción de los elementos de ontología llegamos a la conclusión de que la notación de Osterwalder satisface las necesidades de VDAM. Como se muestra en la figura 4, incluye siete categorías: Nombre del elemento, Definición, Parte de, Relacionado con, conjunto de, cardinalidad y atributos [14]

El nombre y la definición se utilizan para describir específicamente los elementos y crear un entendimiento común. Las categorías Parte de, Relacionado con y Conjunto de se utilizan para describir la relación semántica de elementos entre sí. Generalmente, los elementos se pueden descomponer en subelementos para permitir diferentes niveles de granularidad en el análisis y los siguientes desarrollos de modelos de negocio. Por ejemplo, un elemento la propuesta de valor se puede descomponer en varias propuestas de componentes de valor. La cardinalidad define el número de posibles apariciones de elementos en el enfoque. Por definición la cardinalidad de las entidades de Rol y Propuesta de Valor tiene que ser una.

Las entidades de otros elementos que se utilizan en vistas más detalladas y, por lo tanto, que apoyen la operacionalización pueden tener otras cardinalidades. Esto permite la reutilización de estos elementos durante el proceso de diseño cuando se considere útil. Por ejemplo, una actividad de 'consultoría' puede ser parte de varios meta procesos clave y puede basarse en las mismas capacidades. Finalmente la categoría los atributos definen qué atributos deben usarse para describir entidades de un elemento de ontología.

Proposición de valor elementos ontológicos basado en la notación Osterwalder

Siguiendo la lógica de VDML, se pueden derivar varias vistas del Diagrama de Intercambio de la Propuesta de Valor para respaldar la operacionalización de modelos de negocio en un enfoque integrado. Proponemos el uso de los siguientes tipos de diagramas:

Diagramas de gestión de capacidad para describir el capacidades necesarias para ofrecer una propuesta de valor específica.
Diagramas de actividad de red para diseñar la meta clave de los procesos necesarios para ofrecer propuestas de valor específicas por lo que las actividades necesitan capacidades para ser realizables.
Gráficos de dependencia de medición para mostrar la lógica de creación de valor y contribución de valor.

En consecuencia, estos diagramas permiten una comprensión más profunda de la creación de valor colaborativo entre Roles y por lo tanto apoyando la operacionalización de modelos de negocio.

La creación de esta visión de mercado basada en roles facilita una número de aplicaciones mediante la vinculación de roles a actores, por ejemplo, el propio negocio, socios, competidores u otras partes interesadas, todos líderes a una decisión más informada hacia la implementación de nuevos modelos de negocio.

Uso de la vista de nivel superior de la propuesta de valor Diagramas de intercambio como marco de referencia y resumen de enlace, los roles de una empresa permiten un posicionamiento preciso de los modelos de negocio o la idea del modelo de negocio. Además, este posicionamiento brinda la oportunidad de detectar roles que han aún no se ha considerado o la detección de roles considerados que no encajan en el proceso de creación de valor en el mercado.

Enlace de los roles de los competidores potenciales facilitan la identificación de los lugares y lugares menos competitivos que pueden incluir prometedores oportunidades de negocio.

Usando vistas más detalladas, ajuste entre lo existente y lo necesario para que se pueden establecer capacidades y tomar decisiones sobre asociaciones o se pueda acumular conocimiento. Además, los meta procesos se pueden analizar y definir. Adicionalmente, una comprensión de roles, propuesta de valor, capacidades y se pueden crear actividades y su impacto en la creación de valor.

El caso de la infraestructura de carga rápida en Alemania

Aplicamos nuestro enfoque propuesto en el área de infraestructura de carga rápida en Alemania, evaluando así el diseño del artefacto VDAM [7]. Elegimos este mercado emergente en el área de movilidad eléctrica porque la consideramos un buen ejemplo para los desafíos de muchos de las industrias transformadoras o emergentes de hoy:

Participación de empresas de diversos sectores industriales, a saber, automoción, tecnologías eléctricas, energía y servicios.
Falta de una cadena de valor o red de valor bien establecida y una comprensión ambigua de cómo se crea el valor debido a la novedad de esta zona.
Despliegue de varios estándares tecnológicos y soluciones patentadas, a saber, CHAdeMO combinado sistema de carga y el sistema Tesla.
Falta de un argumento comercial sólido para el funcionamiento de infraestructura de carga basada en la venta de energía, debido a las altas inversiones iniciales y una disposición limitada a pagar. [11,17]

En conjunto, esto crea una situación muy compleja de incierto entorno no favorable a las inversiones directas y el compromiso empresarial. Utilizando métodos de investigación cualitativa, entrevistamos a 17 ejecutivos y los mejores expertos de las empresas que representan a estos diferentes sectores de la industria, preguntando por sus modelos de negocio en y perspectivas sobre este nuevo campo de la infraestructura de carga rápida.

Los datos empíricos revelan una comprensión muy ambigua de cómo se crea valor y quién se supone que debe crear este valor. Además, incluso cuando los expertos hablaban de los mismos temas, la redacción y los términos de uso eran muy heterogéneos, complicando la colaboración exitosa en este nuevo campo. 1

Aplicando nuestro enfoque propuesto a los datos empíricos obtenidos en entrevistas, identificamos 21 roles diferentes que los actores pueden asumir en el ámbito de la infraestructura de carga rápida en el sector eléctrico sector de movilidad, así como su correspondientes proposiciones de valor.

1 Los resultados detallados del estudio se publicarán en Metzger, Kraemer y Terzidis, “A Systemic Approach to Business Modelado basado en el lenguaje de modelado de entrega de valor ”, en: Kuckertz y col. “Complejidad en el espíritu empresarial, la innovación y Investigación tecnológica, Springer Verlag Berlin, 2016 .

Para cumplir con los requisitos definidos para este perspectiva en VDAM, los métodos de abstracción y diferenciación se aplicaron a las declaraciones de los expertos. De ese modo diseñamos un modelo inequívoco y normalizado de creación de valor en el área de infraestructura de carga rápida en Alemania y describió los elementos en una ontología.

Uno de estos roles se llama 'Operador de punto de recarga' (CPO). Todos los expertos mencionaron este papel, pero hubo muchos asociaciones con lo que se supone que debe hacer exactamente este rol y lo que propuestas de valor que este rol está ofreciendo o recibiendo. Razón para este tipo de fenómeno es el hecho de que los expertos estaban hablando sobre su propia empresa o empresas con las que trabajan y que llenan en este papel. Después de analizar en detalle las diferentes opiniones de los expertos, se hizo evidente que el Rol 'CPO' ofrece el Valor Propuesta 'infraestructura de trabajo para usuarios de vehículos eléctricos' al rol Inversor. Para describir explícitamente el Rol, una primera versión se desarrolló de la entidad de ontología 'CPO'.

En el enfoque iterativo de analizar opiniones de expertos y definir roles y propuestas de valor, el diagrama de intercambio de las propuestas de valor crecía y cambiaba constantemente (ver Figura 5).

Simultáneamente, el elemento de ontología correspondiente del Rol 'CPO' se hizo más detallado y otros elementos relacionados de ontología de roles y propuestas de valor fueron descritos, creando así la comprensión inequívoca deseada de elementos y la creación de valor. En el caso de infraestructura de carga rápida, se hace evidente que el Rol 'CPO' es principalmente el de organizar las operaciones reales de la infraestructura de carga mediante la coordinación con varios roles y sus propuestas de valor y ofreciendo el resultado al Rol 'Inversor'. Además un segunda propuesta de valor 'Acceso a puntos de recarga' se ofrece al Rol del 'proveedor de movilidad eléctrica.

Proceso iterativo y la construcción ontológica VDAM

En varias iteraciones logramos trazar un mapa de vista inequívoco del complejo intercambio y la creación de valor en el área de infraestructura de carga rápida en Alemania (ver Figura 6).

La vista resultante incluye 21 roles que los actores pueden desempeñar y 29 propuestas de valor que ofrecen estos roles. El Diagrama de valor de intercambio de entrega y la ontología correspondiente permiten la deducción de los tipos de diagramas más detallados para apoyar la puesta en funcionamiento de posibles modelos de negocio.

Diagrama de intercambio de propuesta de valor del
sector de infraestructura de carga rápida en Alemania

Además, facilita varias aplicaciones relativas al análisis y desarrollo de modelos de negocio. Por ejemplo, analizando el diagrama de intercambio de propuesta de valor y vinculación del rol 'CPO' a los actores, a saber, las empresas entrevistadas, una serie de las conclusiones que se pueden derivar:

El rol está altamente interconectado con otros roles y tiene una posición central en la red de valor.
La coordinación de varios roles crea y agrega valor.
Siete de las empresas entrevistadas afirman que rellenan este Rol y otros cuatro mencionaron que consideran una empresa que cumple este rol como socio estratégico.
Todas las empresas del sector Energía cumplen este Rol
Todas las empresas, excepto una, que cumplen el rol de 'CPO' también cumplen al menos uno de los roles directamente relacionados a través de una propuesta de valor.

En conjunto, podemos concluir que el rol 'CPO' es un importante papel en la red de valor y es altamente competitivo. Especialmente empresas del sector de la Energía reclaman este Rol porque también cumplen algunos otros roles estrechamente relacionados.

Discusión

Como se muestra arriba, VDML busca llenar el vacío entre la estrategia y procesos de negocio, apoyando la operacionalización de ideas e innovación de modelos de negocio. El desarrollo de una ontología apoya la creación de un entendimiento común entre todas las partes involucradas en el proceso de diseño y ayuda al operacionalización de modelos de negocio.

Esto es de especial importancia para el modelado de negocios en sectores industriales con alta niveles de incertidumbre, la necesidad de colaboración entre industrias y una falta de entendimiento común, como el electro de hoy sector de la movilidad. La combinación de estos dos conceptos con la implementación de una perspectiva abstracta sobre la creación de valor incluida la vinculación posterior de roles abstractos a actores demostró ser un enfoque muy útil para análisis y negocios modelo de innovación y creación.

Como se muestra en el ejemplo del rol 'CPO', Entrega de valor El modelado de arquitectura crea transparencia y desenreda complejidad, facilitando varias aplicaciones en el emergente mercado de la infraestructura de carga rápida en Alemania:

Creando una perspectiva inequívoca sobre cómo es el valor creado incluyendo capacidades, meta-procesos clave y contribución de valor.
Posicionamiento preciso de las empresas analizadas en este red compleja de creación de valor y facilitando una mejor comprensión de su creación de valor e impacto en valor.
Analizar y comparar los modelos de negocio de la empresas descritas por los expertos.
La posibilidad de desarrollar nuevas ideas de modelos de negocio incluyendo un posicionamiento preciso en la creación de valor red incluida la definición de asociaciones útiles.
Definición de un modelo de colaboración para la creación de valor y desarrollo de negocio para empresas de diferentes Sectores industriales, por ejemplo, automoción, energía y electricidad industria.

Análisis de mercado, abstracción, visualización en diagramas y La descripción textual en una ontología requiere cierta preparación y tiempo de desarrollo. Sin embargo, esta carga frontal da como resultado

ventajas distintivas para la innovación o creación de modelos de negocio por varias razones: en primer lugar, estos pasos son un requisito previo para crear una visión clara de la creación de valor, incluidas las capacidades, los procesos y aporte de valor en situaciones inciertas y complejas entornos empresariales. Además, el análisis de la competencia Profundiza la comprensión de los potenciales y las amenazas del negocio. ideas modelo. Finalmente, el diagrama de intercambio de la propuesta de valor

permite a la alta dirección tomar decisiones rápidas pero informadas sobre potencial innovación o creación de modelos de negocio, mientras que es posible la operacionalización está respaldada por las vistas subyacentes y diagramas.

Conclusión

Basándonos en los prometedores resultados de nuestro estudio, confiamos en que El modelado de la arquitectura de entrega de valor es valioso para los investigadores y practicantes. Como ilustra el ejemplo anterior, VDAM puede crear transparencia y claridad en la creación de valor complejo redes y por lo tanto apoya la descripción, desarrollo y operacionalización de modelos de negocio dentro de un integrado Acercarse.

Reflexionando sobre la situación, observamos que el VDAM propuesto El enfoque es particularmente adecuado para redes de valor complejas. como aparecen en el ejemplo de la infraestructura de carga rápida en Alemania con 21 socios comerciales y el correspondiente complejidad. Esta industria emergente se caracteriza por la necesidad de un alto grado de colaboración entre industrias para

crear valor en las redes. Un cambio de paradigma en un El entorno interdependiente requiere una comprensión común de la creación de valor y la colaboración y el enfoque pueden ayudar a crear tal entendimiento.

No obstante, somos conscientes de que los prometedores resultados de la La aplicación del artefacto VDAM debe ser confirmada en el futuro. estudios e investigaciones. Identificar oportunidades adicionales y Las limitaciones serán valiosas para validar y mejorar aún más VDAM. Por tanto, y debido a la novedad de VDML, Fomentar la aplicación y validación adicionales en diferentes sectores empresariales. De particular interés son las aplicaciones en áreas de transformación entre sistemas o industrias emergentes, ya que ocurren repetidamente en el entorno económico actual.

Referencias

[1] M. Al-Debei y D. Avison, “Developing a unified marco del concepto de modelo de negocio ”, European Revista de sistemas de información , vol. 19, N ° 3, 2010, págs. 359-376
[2] P. Ballon, "Business Modeling as the Configuration of Control y valor ". BLED Proceedings , 2007, Vol. 9 No. 5, 2007, págs.6-19
[3] A. Berre et al., “Business Model Innovation with the Plataforma NEFFICS y VDML ”, NGEBIS'2013 taller en CAISE , 2013, págs. 24-30
[4] A. Berre et al., “Service Innovation and Service Realization con VDML y ServiceML ”, Enterprise Distributed Talleres de conferencias sobre computación de objetos (EDOCW) , IEEE International, 2013 págs. 104-113
[5] A. Berre et al., “Open Business Model, Process and Service Innovación con VDML y ServiceML ”, Enterprise Interoperabilidad: investigación y aplicaciones en servicio Ecosistema orientado, Actas de la 5a Internacional Conferencia de trabajo de IFIP , IWIE, 2013
[6] H. Chesbrough y RS Rosenbloom, “The Role of the Modelo de negocio en la captura de valor de la innovación: Evidencia de la tecnología de XEROX Corporation Empresas spin-off ”. Boston, Massachusetts, Harvard Escuela de Negocios, 2000
[7] A. Hevner et al., “Design Science in Information System Investigación ”, MIS Quarterly , vol. 28, núm. 1, 2004, págs. 75- 105
[8] P. Lindgren, "El cubo del modelo de negocio", Journal of Multi Innovación y tecnología del modelo de negocio , RiverPublishers, 2013, págs. 135-182
[9] J. Magretta (2002), "Por qué importan los modelos de negocio", Harvard Business Review , 2002.
[10] S. March y G. Smith, “Design and natural science research sobre tecnología de la información ”, Sistemas de apoyo a la toma de decisiones ,Vol. 15, 1995, págs. 251-266
[11] Plataforma nacional Elektromobilität, Fortschrittsbericht 2014 - Bilanz der Marktvorbereitung , Berlín, 2014
[12] Grupo de gestión de objetos, modelado de entrega de valor Language FTF Beta 1 , obtenido de http://www.omg.org/spec/VDML/1.0/Beta1/PDF/, 2014
[13] Grupo de gestión de objetos, modelado de entrega de valor Language FTF Beta 2 , obtenido de http://www.omg.org/spec/VDML/1.0/Beta2/, 2015
[14] A. Osterwalder, The Business Model Ontology - A propuesta en un enfoque de ciencia del diseño , 2004
[15] A. Osterwalder et al, “Clarifying business models: Origins, presente y futuro del concepto ”, Comunicaciones de la asociación de sistemas de información , vol. 16 de 2005
[16] A. Osterwalder & Y. Pigneur, Generación de modelos de negocio: un manual para visionarios, revolucionarios y retadores , Hoboken, Nueva Jersey: John Wiley & Sons, 2010.
[17] J. Reinke, Bereitstellung öffentlicher Ladeinfrastruktur für Elektrofahrzeuge: eine Institutionenökonomische Analyse , Berlín, 2014
[18] B. Roelens y G. Poels, “Towards a Strategy-Oriented Lenguaje de modelado de valor: identificación de elementos estratégicos del metamodelo VDML ”, Modelado conceptual , Springer, págs. 454-462
[19] H. Simon, "Las ciencias de lo artificial", MIT Press ,1996
[20] M. Uschold y M. Grunninger, “Ontologías: Principios, métodos y aplicaciones ”, The Knowledge Engineering Revisión , vol. 11, núm. 2, 1996, págs. 93-136
[21] MD Torbay et al., “Diseño de modelos de comercio electrónico, clasificación y mediciones ”, Thunderbird International Business Review , vol. 44, núm. 1, 2001, págs. 5–23

DSN_XP y los métodos ágiles

¿Metodologías ágiles realmente diferentes?

Documento de posición para el taller OOPSLA 2003

Jens Coldewey

Consultoría Coldewey

correo electrónico: jens_coldewey@acm.org

http://www.coldewey.com

Enfoques de una metodología

Además de considerar los procesos que una metodología supone utilizar, otro tema de interés para estudios es el modelo que subyace a la metodología. Aunque esto está estrechamente relacionado con el valor del sistema, el modelo no soporta juicio ético, como lo hace un sistema de valores.

Hay dos modelos populares para proyectos: el modelo de control y el modelo sistémico. El modelo de control asume que hay roles de dirección centralizados en un proyecto, individuos capacitados que planifican y gestionan el proyecto. Estos roles incluyen el gerente de proyecto, el arquitecto, el jefe de programación, etc. Con este enfoque, el éxito y el fracaso del proyecto depende principalmente del desempeño de estos roles de control. Me referiré a estos roles como los "gerentes", aunque esto incluye todo tipo de gestión y control.

Metodologías que utilizan este enfoque usualmente se concentran en los elementos que apoyan esta estructura:

Mejorar la comunicación entre los gerentes y los miembros del equipo operativo, como programadores.
Proporcionar estructuras de control y presentación de informes para permitir que los gerentes obtengan una buena imagen del estado del proyecto.
Asegurar que el trabajo operativo se realice de la manera más uniforme posible para facilitar la planificación, la predicción y control. Se supone que los miembros del equipo desempeñan determinados roles y se intercambian "recursos" capaces.
Clara separación de responsabilidades.

El último extremo de esta apreciación es Frederick Taylors, Scientific Management que estableció el terreno para el impulso económico del siglo pasado. La mayoría de los procesos tradicionales siguen este modelo.

Un enfoque alternativo es ver un proyecto como un sistema complejo. Los sistemas complejos tienen algunas características que las estructuras de comando y control no tienen: Su comportamiento es difícil de predecir y son muy flexibles. Controlar un sistema complejo no significa predecir y controlar cada acción única en él. Más bien significa comprender la estructura y las interrelaciones del sistema y configurarlos para que el sistema se adapte a las necesidades.

El pensamiento sistémico proporciona el conjunto de herramientas apropiado para este tipo de enfoque.

Metodologías basadas en el pensamiento sistémico, ya sea de forma consciente o no, muestran algunas propiedades típicas:

Pocas reglas. La mayoría de las reglas establecen circuitos de retroalimentación y comunicación para asegurar que todas las partes del proyecto todavía se dirigen hacia el objetivo del proyecto.
La retroalimentación y la comunicación están diseñadas para ser lo más eficientes posible, en lugar de ser rastreable o controlable.
Pocos o ningún rol centralizado o jerárquico. Se asume que los miembros del equipo están bien capacitados, personas responsables que sean capaces de organizarse.

Comparación de los enfoques de las metodologías ágiles

La siguiente lista comprueba a qué enfoque pertenecen las diferentes metodologías ágiles:

Desarrollo de software adaptativo: ASD

Es la única metodología que se basa explícitamente en la teoría de los sistemas adaptativos complejos, se limita a establecer un circuito de retroalimentación. ("Especular, colaborar, aprender") y configurar el entorno para un trabajo de proyecto eficiente. Un representante clásico del enfoque sistémico.

Metodologías Crystal:

El principal punto en común de todas las metodologías Crystal es un taller de verificación de los procesos al menos dos veces por incremento. Además, Cockburn ofrece siete principios a observar en un proyecto. Los roles y las organizaciones solo se proporcionan como sugerencias. Otro ejemplo de enfoque de sistemas

Método de desarrollo de software dinámico: DSDM

Define roles y responsabilidades explícitos como núcleo de la metodología. Se provocan bucles de retroalimentación para la entrega (entrega frecuente, todos los cambios son reversibles) pero no a nivel de proceso. Por tanto, DSMD utiliza un sistema de enfoque para dejar crecer el software pero un modelo de control para gestionar el proyecto.

Programación extrema: XP

Usa solo unas pocas reglas para configurar un entorno en el que el software puede crecer. Por tanto, la parte técnica utiliza claramente un enfoque de sistemas. En cuanto a la metodología XP mostró un desarrollo interesante en los últimos años. Aunque la metáfora de Kent Beck de "Aprender a conducir" apuntaba hacia un modelo de sistemas, declaraciones iniciales como "O haces todo como está escrito o no haces XP" a menudo se interpretaba como una señal para un modelo de control. Al darse cuenta de que estas declaraciones llevaron a XP en una dirección no deseada, la comunidad ahora acuerda la adaptación regular del proceso. Por lo tanto, XP puede ser considerada una metodología de sistemas en la actualidad.

Desarrollo impulsado por Funcionalidades: FDD

Instala el rol de programador jefe y utiliza diseños basados en actualizaciones de frente al usario. Por lo tanto, FDD en mi percepción claramente utiliza un enfoque de control en lugar de utilizar una visión sistémica, aunque definitivamente es un proceso ligero.

Desarrollo Lean:

La mayoría de las prácticas técnicas de LD son similares a lo que XP encontró útil, así que técnicamente LD también se basa en un modelo de sistemas. La gestión está muy centrada en auto organización y retroalimentación: indicadores para un modelo de sistema también.

Scrum:

Define un ciclo de retroalimentación central como instrumento de control principal que identifica a Scrum como metodología sistémica. Esto se suma al hecho de que scrum define pocos roles con el papel central del "Scrum Master" quien tiene la responsabilidad principalmente de facilitar el proceso en lugar del entregable.

Una conclusión sugerente

Sugiero definir el desarrollo ágil como una metodología basada en una visión sistémica del desarrollo de software. Esta visión conduce a los principios ágiles, así como a muchas metodologías ágiles.

Usar esta definición significaría reevaluar la comprensión actual de qué las metodologías son ágiles y las que no lo son. Según la lista anterior, esto reduciría el "completamente ágil" a metodologías como ASD, Crystal, XP en su forma actual, Lean Development y Scrum. DSDM se considerarían una metodología "técnicamente ágil" y la FDD se consideraría un proceso tradicional pesado.

DSN_XP y los contratos ágiles

Contratos ágiles

Dentro de la perspectiva de negocio para DSN_XP o BusinessView, siempre nos adaptamos a la mirada de nuestros clientes, pues comprendemos que, nuestra línea de servicios de soluciones a necesidades por experimentación es tan amplia y rica en escenarios como nuestro portafolio de clientes sea establecido.

¿Qué son los contratos ágiles y cómo puedo aplicarlos?

La forma de desarrollar software desde hace años no encaja en el mundo digital actual, ahora se solicita ser "agile", entonces pensamos si es posible ya introducir bajo este contexto el dominio de la contratación ágil.

Hemos visto la necesidad de estudiar herramientas que nos permitan aplicar relaciones comerciales basadas en el respeto y el consumo inteligente. Dentro de estos aspectos, es necesario un estudio de los tipos de contratos que pueden presentarse en cualquier escenario de negociación, para efectos de lograr acuerdos basados en diseños que contemplan: modelos ganar, ganar, ganar, modelo ético que propone emplear un esfuerzo para crecer por uno mismo, al crear por los demás y cocrear por el mundo.

Campo contractual bajo la perspectiva legal

Pero no basta con tenerlo claro, el camino es complicado y entre otros obstáculos, los contratos tradicionales no ayudan. El problema ya es conocido: querer jugar a un juego con las reglas de otro.

Tomado de la fuente principal de consulta

Por cultura general, un contrato es un acuerdo entre un proveedor y un cliente en el cual se define el objeto del acuerdo, el pago acordado por dicho objeto y las condiciones para la prestación del servicio o la entrega-recepción del bien.

Todo lo que no sea contrario a la ley, a la moral ni al orden público puede ser pactado contractualmente, sin otras limitaciones que las expuestas. Por ello, el uso de contratos se refieren a cuestiones previstas y expresamente reguladas en la ley (como la compra venta, el arrendamiento, el préstamo, la sociedad, la permuta, el trabajo, etc.) y otras se refieren a cuestiones no previstas y reguladas por la ley. Los primeros son los llamados contratos nominados y los segundos los contratos innominados.

Uno de los factores motivadores para diseñar DSN_XP fue la perspectiva legal que se requería para la administración de los contratos por los servicios de desarrollo de software en Ecuador. El objeto de contratación en su término más abstracto se denomina software y como tal es necesario definirlo para evitar más tarde un entendimiento diferente según la perspectiva de uso que tenga de ese software.

LegalView

La obligatoriedad

La relación derivada de los contratos no tendría eficacia ni serviría de nada, si su cumplimiento no fuese obligatorio, porque de otro modo, el contratante de buena fe estaría siempre a merced del contratante malicioso. Para evitar esto, los códigos han establecido el principio de que los contratos tienen fuerza de ley entre quienes lo celebran.

La obligatoriedad de los contratos no solo afecta a los contratantes sino también a las personas que ellos tengan causa, es decir, a sus sucesores y dado que basta que las partes contratantes queden en lo que constituye "el pacto" para el que el contrato quede, sin más requisitos, perfeccionado. Además , la obligación de cumplir el compromiso no sólo se extiende a lo expresamente convenido sino también a todas las consecuencias que, según la naturaleza, sean conformes a la ley, al uso y a la buena fe.

Consecuencia de esta obligatoriedad y de la fuerza de ley atribuidas por norma, también referida en los códigos, sobre la validez y el cumplimiento de un contrato, pueden surgir diferencias entre las partes respecto a su interpretación; diferencia que muchas veces tiene un origen justificado en el hecho de que al momento de celebrarse "el pacto" cada contratante daba al compromiso un alcance distinto. En tal hipótesis, la intención de los contratantes se determina por el sentido literal de sus cláusulas cuando son claras; pero si las palabras parecieren contrarias a la intención de los contratantes, determinada por los actos anteriores, posteriores al contrato y también por el uso y la costumbre, la intención prevalece sobre las palabras.

Rescisión de los contratos

Con igualdad de libertad que las partes pueden contratar, pueden rescindir voluntariamente y de común acuerdo lo contratado, si bien dejando a salvo los derechos creados a favor de terceros. Pero además del mutuo consentimiento, existen causas legales para la rescisión de los contratos. Entre las principales causas de rescisión se pueden señalar las siguientes:

Contratos celebrados por tutores con o sin autorización de la familia, siempre que sus representados hayan sufrido lesión en determinada parte del valor de las cosas que hubieran sido objeto de aquellos.
Contratos celebrados en representación de los ausentes, si éstos han sufrido lesión en determinada cuantía.
Contratos celebrados en fraude de acreedores.
Contratos referidos como en litigio, a menos que medie el consentimiento de los litigantes o el permiso de la autoridad judicial.
Los afectados de vicios, redhibitorios (vicios ocultos) en la cosa objeto del contrato.
Aquellos en que una persona por su penuria, por su ligereza o por su inexperiencia, hubiese aceptado una evidente desproporción entre la prestación de su parte y la contraprestación de la otra.

¿Es necesario un contrato?

Hablar de contratos ágiles requiere poner como referente al manifiesto ágil y sus principios de funcionamiento, entre ellos, ¿los contratos ágiles aplican solo para el desarrollo de software?

Si la propuesta del manifiesto implica y como lo es, un MINDSET o forma de mirar al desarrollo de software, su aplicación contempla aspectos mucho más allá de desarrollar software y se descubre todo un contexto colaborativo con miras a lograr mejores formas de enfrentar proyectos que contemplan como objeto el desarrollo de software.

Para poder dejar en claro ante terceros que, un contrato ágil, es un contrato y por tanto debe someterse a la perspectiva legal tal cual lo hace cualquier otro contrato, por ello es que traemos un análisis de los diversos escenarios en los cuales, no solo se negocia el contexto del desarrollo de software sino que, inclusive un proceso de transformación organizacional y culturalmente hablando, espacios no contemplados bajo los esquemas tradicionales, cubiertos por aquellos criterios legales que se utilizan con el argumento de proteger al contratante de un riesgo que es muy evidente por tratarse de un objeto de contrato cuya naturaleza no puede ser considerada en la mayoría de sus aspectos como tangible lo que lo convierte en un tipo de servicio.

Ahora bien, para lograr entender los actores que existen detrás de un contrato ágil se requiere entender primero el propósito de un contrato.

Propósito contractual

Los contratos son un conjunto de reglas de juego para el proyecto. En teoría, estas reglas se acuerdan libremente por ambas partes para crear condiciones óptimas que permitan completar con éxito el proyecto. En la práctica, a los contratos se los suele ver como juegos competitivos, en el cual el objetivo es dejar en desventaja a la otra parte, especialmente cuando las cosas van mal. Muchas organizaciones grandes y gobiernos tienen condiciones comunes que tienen que aceptarse en conjunto como pre-requisito para hacer negocios con ellos. Estas condiciones casi nunca son justas, por lo cual un resultado razonable para un proyecto depende en gran medida de la buena relación con el cliente, evitando discutir el contrato o recurrir a la ley (el Manifiesto Ágil hace un punto importante acá: la relación con el cliente es más importante que el contrato escrito!).

Nuevamente, es cuestión de un MINDSET que soporte el modelo propuesto de colaboración sobre un modelo de aspecto legal que conduce a la negociación entre las partes y ya no al desarrollo de software, sino que se limita a un conjunto de argumentos legales construidos previamente que se aplican en momentos de crisis para supuestamente proteger a una de las partes.

DOD como cliente detrás de la industria del software

Dada la aplicación sustancialmente de las matemáticas al desarrollo tanto de la estructura del software como de su distribución y desarrollo en la industria del hardware, el software en su formato de aplicación de una estructura abstracta que se transforma en lenguaje de máquina termina en un concepto claro de procesamiento de datos a mayor velocidad que el humano y la toma de decisiones que modelan al flujo de esta información.

La lucha que se tiene en aspectos que implican al desarrollo de software como el componente que define el comportamiento de un sistema considerado como autómata basado tanto en imperativos que restringen su operatividad como software, ya sea computable o como estructura de datos, se veían reflejados en una estructura documental (por aspectos de requerimientos legales por uso de fondos públicos o por cualquier otra restricción de seriedad en el proceso de contratación).

DSN_XP y la OTAN 1968

Sobre los informes técnicos del software

Reuniones de la OTAN

Dagstuhl-Seminar 9635:

"History of Software Engineering" Schloss Dagstuhl,

August 26 - 30, 1996

The 1968/69 NATO

Software Engineering Reports

Tomado como fuente original a este enlace

Brian Randell

Departamento de Ciencias de la Computación

Universidad de Newcastle upon Tyne

Informes técnicos de ingeniería de software 1968/69

Reuniones Ingeniería de Software OTAN

La idea de la primera Conferencia de Ingeniería de Software de la OTAN y en particular la de adoptar el entonces prácticamente desconocido término "ingeniería de software" como su título (deliberadamente provocador), creo que vino originalmente del profesor Fritz Bauer.

F.L. Bauer

Del mismo modo, si mi memoria no me falla, fue él quien destacó la importancia de proporcionar un informe sobre la conferencia y quien nos convenció a Peter Naur y a mí de ser los editores. (En ese momento trabajaba en IBM TJ Watson Research Center en los EE. UU., Pero conocí a "Onkel Fritz" por haber sido miembro del Comité IFIP Algol durante varios años).

B.Randell

P. Naur

Como resultado, se acordó que Peter y yo nos quedaríamos una semana más después de la conferencia para editar el borrador del informe, aunque acordamos trasladarnos de Garmisch-Partenkirchen a Munich durante esta segunda semana.

Conferencia sobre el software

Citando nuestro Informe de la Conferencia de 1968 [Naur y Randell, enero de 1969]:

"El trabajo real en el informe fue una empresa conjunta de varias personas. La gran cantidad de mecanografía y otras tareas de oficina, tanto durante la conferencia como durante un período posterior, fueron realizadas por la señorita Doris Angemeyer, la señorita Enid Austin, la señorita Petra Dandler, la señora Dagmar Hanisch y la señorita Erika Stief.

Durante la conferencia, Larry Flanigan, Ian Hugo y Manfred Paul tomaron notas. Ian Hugo también manejó la grabadora. La revisión y clasificación de los pasajes de las contribuciones escritas y las discusiones estuvo a cargo de Larry Flanigan , Bernard Galler, David Gries, Ian Hugo, Peter Naur, Brian Randell y Gerd Sapper.

L.K. Flanigan

I.Hugo

M. Paul

B. Galler

D. Gries

La redacción final fue realizada por Peter Naur y Brian Randell. La preparación de la copia final mecanografiada del informe fue realizada por la señorita Kirsten Anderson en Regnecentralen, Copenhague, bajo la dirección de Peter Naur ".

Aportes colectivos

Reuniones OTAN

Como yo y otros participantes hemos testificado desde entonces, se desarrolló una atmósfera tremendamente emocionada y entusiasta en la conferencia. Esto fue cuando los participantes se dieron cuenta del grado de preocupación común acerca de lo que algunos estaban dispuestos a denominar la "crisis del software" y surgió un acuerdo general sobre la importancia de tratar de convencer no solo a otros colegas, sino también a los responsables políticos en todos los niveles. de la gravedad de los problemas que se estaban discutiendo.

Por lo tanto, a lo largo de la conferencia hubo un énfasis continuo en cómo se podía informar mejor de la conferencia. De hecho, al final de la conferencia, Peter y yo habíamos recibido una propuesta de estructura detallada para la parte principal del informe. Esto se basó en una estructuración lógica de los temas cubiertos, en lugar de seguir un modelo estricto de la forma real en que la conferencia sucedió.

Peter y yo estuvimos muy contentos de tener tal orientación sobre la estructura y el contenido general del informe, ya que ambos deseábamos crear algo que fuera verdaderamente un informe de conferencia, en lugar de un mero informe personal sobre una conferencia a la que habíamos asistido.

De hecho, Peter argumentó que no deberíamos proporcionar ningún texto adicional nosotros mismos, sino que deberíamos producir la parte principal del informe simplemente completando la estructura acordada con citas directas adecuadas de contribuciones habladas y escritas a conferencias.

Sin embargo, le convencí de que breves introducciones editoriales y pasajes de enlace mejorarían la continuidad y la legibilidad general del informe. Entonces, (junto con la decisión de que una pequeña selección de los textos escritos también se incorporarían en su totalidad como apéndices), llegamos a la forma final del informe.

Documentación técnica

En Munich trabajamos a partir de las notas tomadas por los relatores, que habíamos arreglado para que fueran tecleadas, tal como se hicieron, a los números de las grabaciones en las cintas grabadas. Las cintas no se transcribieron sistemáticamente, ya que este proceso suele tardar entre cinco y seis veces en tiempo real. Más bien, usamos las notas de los relatores y nuestras memorias para localizar secciones particularmente interesantes y oportunas de las cintas y solo estas fueron transcritas.

De esta manera construimos un gran conjunto de citas transcritas, que complementamos con citas adecuadas de las contribuciones escritas. Luego, para cada sección del informe, uno u otro de nosotros intentó convertir el conjunto relevante de citas en un relato coherente y pseudo-literal de la discusión sobre ese tema.

El trabajo en Munich fue tan agradable como intenso y brindó muchas oportunidades para volver a escuchar algunas de las discusiones más memorables, de modo que muchas de ellas quedaron grabadas mucho más profundamente en mi memoria y tuvieron un efecto más fuerte en mis posteriores investigaciones, de lo que hubiera sido el caso si yo simplemente hubiera participado en la conferencia.

El informe estaba prácticamente completo al final de la semana en Munich, y luego Peter Naur se llevó todo con él a Copenhague, donde se produjo un primer borrador completo utilizando una máquina de escribir controlada por cinta de papel (supongo que era un redactor flexible), una técnica que parecía novela en ese momento, pero que él nos aconsejó acertadamente ayudaría mucho en la preparación de un texto final preciso.

Cuerpo de conocimientos

(Mi memoria me dice que este borrador se circuló luego a los participantes para comentarios y correcciones antes de ser impreso. La impresión y distribución reales fueron realizadas por la OTAN, y el Informe estuvo disponible en enero de 1969, solo tres meses después de la conferencia.

Las copias se distribuyeron gratuitamente a pedido y rápidamente logró una amplia distribución y atención. Una de las reacciones más agradables entre los participantes fue la de Doug McIlroy, quien lo describió como "¡un triunfo de las citas mal aplicadas!". (Fue solo muchos años después que supe por un breve artículo de Mary Shaw que Al Perlis entregó copias del informe a los estudiantes graduados en ciencias de la computación de CMU con las palabras "Aquí, lea esto. Cambiará su vida". [ Shaw 1989])

Tal fue el éxito de la primera conferencia que los organizadores buscaron y obtuvieron el patrocinio de la OTAN para una segunda conferencia, que se celebraría un año después en Italia.

Peter Naur, sabiamente, no estaba dispuesto a repetir su labor editorial, pero yo, más bien precipitadamente, después de algunas dudas iniciales acepté hacerlo, esta vez en cooperación con John Buxton.

Según recuerdo, los planes para la segunda conferencia se discutieron en una reunión celebrada en una oficina en la sede de la OTAN. Mi principal recuerdo es que la oficina estaba presidida por una caja fuerte muy grande e impresionante, que para mi diversión se reveló completamente vacía cuando nuestro anfitrión, al final de la reunión, la abrió para guardar las botellas de las que bebe y que nos habían servido antes.

Durante estas discusiones preparatorias proporcioné, basado en mi experiencia ganada con esfuerzo en Munich, lo que con orgullo consideré una lista muy bien pensada de requisitos con respecto a las instalaciones que necesitaríamos tener en Roma. (El más importante de ellos fue que el equipo editorial debería tener acceso a tiempo completo a un hablante de italiano que ayudaría a resolver cualquier dificultad que pudiera surgir, de esto, más adelante).

Mi (sobre) confianza inicial también se debió en parte al hecho de que esta segunda vez, a John y a mí nos habían ofrecido los servicios de tiempo completo de dos escritores técnicos experimentados de ICL, a saber, Ian Hugo (que había estado muy involucrado en la preparación del primer informe) y Rod Ellis, y cada uno de nosotros había dispuesto que nos acompañaran a Roma una secretaria experta, Margaret Chamberlain y Ann Laybourn, respectivamente.

Ian, por cierto, pasó a ayudar a fundar Infotech, una empresa que posteriormente, durante un período de años, organizó una gran cantidad de conferencias técnicas, cada una de las cuales condujo a la publicación de un Informe sobre el estado del arte, cuyo formato coincidía estrechamente al de los informes de la OTAN.

Segunda conferencia

Informe de conferencia

En el evento, la segunda conferencia fue mucho menos armoniosa y exitosa que la primera y nuestra tarea editorial resultó ser muy diferente. Citando nuestra introducción al Informe de la Conferencia de 1969 [Buxton y Randell, abril de 1970]:

Finalmente, la seriedad de esta brecha de comunicación y la comprensión de que no era más que un reflejo de la situación en el mundo real, hicieron que la brecha en sí se convirtiera en un tema importante de discusión. . . . . En vista de estos acontecimientos, no es de extrañar que los editores no recibieran un resumen claro de la conferencia en cuanto a la estructura y contenido del informe ".

Por lo tanto, la tarea de producir un informe que fuera a la vez respetable y razonablemente preciso fue mucho más difícil de lo que podría haber imaginado y no fue ayudado por todo tipo de dificultades que sufrimos, casi todas las cuales se habrían resuelto mucho más fácilmente si se había proporcionado un organizador local según lo acordado. No obstante, algunos de los participantes expresaron su grata sorpresa por nuestro informe, cuando recibieron posteriormente un borrador para su verificación, y evidentemente lo consideraron más positivamente que la conferencia que pretendía documentar.

... Todas estas adversidades, cuyo impacto habría sido mucho menor si hubiéramos tenido el asistente local prometido, de hecho ayudaron a unirnos como equipo. El brillante don de Rod Ellis para el mimetismo también ayudó al proporcionar muchos momentos agradables de hilaridad general, ya que, adaptando su elección al tema en cuestión, intercambió sin esfuerzo conversaciones con nosotros entre las voces de Edsger Dijkstra, Fritz Bauer y muchos de los demás participantes cuyos comentarios de la conferencia habían sido capturados para la posteridad por nuestras grabadoras.

De hecho, terminamos el informe temprano el viernes por la noche, a tiempo para una cena de celebración final, una vez que Rod e Ian habían regresado de la Universidad de Roma, donde habían hecho copias del informe preliminar (y, de manera bastante apropiada, roto la fotocopiadora). Sin embargo, fue en consonancia con el resto de la semana que casi todos los camareros de restaurantes en Roma eligieron ese momento para ir a la huelga; de hecho, vimos una gran procesión de ellos desfilar frente a nuestras ventanas gritando y agitando pancartas, de modo que tuvimos que contentarnos con una excelente cena en el hotel.

Algo que había olvidado por completo hasta que volví a leer la introducción del Informe de 1969 mientras preparaba este breve relato fue que este segundo informe se redactó en la Universidad de Newcastle upon Tyne, a donde me había mudado de IBM en el ínterin. De hecho, algunos de los primeros trabajos del mundo sobre composición tipográfica informatizada se habían realizado en Newcastle. Citando del informe: "La versión final del informe fue preparada por Kynock Press, utilizando su sistema de tipografía por computadora (ver Cox, NSM y Heath, WA: 'La integración del proceso de publicación con datos manipulados por computadora'. Papel presentado en el Seminario sobre sistemas de publicación automatizados, 7-13 de septiembre de 1969, Universidad de Newcastle upon Tyne, Proyecto de investigación de composición tipográfica por computadora), el procesamiento preliminar del texto se realizó utilizando el sistema de manejo de archivos de Newcastle.

A diferencia de la primera conferencia, en la que se aceptó plenamente que el término ingeniería de software expresaba una necesidad más que una realidad, en Roma ya existía una ligera tendencia a hablar como si el tema ya existiera. Y quedó claro durante la conferencia que los organizadores tenían una agenda oculta, a saber, la de persuadir a la OTAN para que financie la creación de un Instituto Internacional de Ingeniería de Software. Sin embargo, las cosas no salieron según su plan. Las sesiones de discusión que estaban destinadas a proporcionar evidencia de un fuerte y amplio apoyo a esta propuesta estuvieron marcadas por un considerable escepticismo y llevaron a uno de los participantes, Tom Simpson de IBM, a escribir una espléndida sátira corta sobre " Masterpiece Engineering ".

John y yo decidimos más tarde que el texto de Tom Simpson proporcionaría un conjunto apropiado, aunque algo irreverente, de observaciones finales a la parte principal del informe. Sin embargo, en el evento fuimos "persuadidos" por los organizadores de la conferencia para eliminar este texto del informe. Estoy seguro de que esto se debió únicamente a sus referencias sarcásticas a un "Instituto de ingeniería de obra maestra". Siempre he lamentado que cediéramos a la presión y permitiéramos que nuestro informe fuera censurado de esa manera. Entonces, a modo de expiación, adjunto una copia del texto como Apéndice a este breve conjunto de reminiscencias.

No fue una sorpresa para ninguno de los participantes en la conferencia de Roma que no se hiciera ningún intento de continuar la serie de conferencias de la OTAN, pero el tren de la ingeniería de software comenzó a rodar a medida que muchas personas comenzaron a usar el término para describir su trabajo, en mi opinión a menudo con muy poca justificación. Reaccionando a esta situación, durante muchos años hice un punto particular de negarme a usar el término o estar asociado con cualquier evento que lo usara. De hecho, no fue hasta unos diez años después que cedí, al aceptar una invitación para ser uno de los oradores invitados en la Conferencia Internacional de Ingeniería de Software en Munich en 1979.

Los otros oradores invitados fueron Barry Boehm, Wlad Turski y Edsger Dijkstra. Me pidieron que hablara sobre ingeniería de software como era en 1968, Barry sobre el estado actual, Habló sobre el futuro de la ingeniería de software y Edsger sobre cómo debería desarrollarse. Me divertí mucho preparando mi artículo [Randell 1979] ya que incluí numerosos desafíos implícitos a Barry, cuya charla estaba programada inmediatamente después de la mía, para justificar afirmaciones sobre el progreso desde 1968. Ignoró cuidadosamente todos estos desafíos, o tal vez no los reconoció. Lamento decir.

En mi intento de 1979 de describir la escena de 1968/9, no me pareció apropiado insistir en mis experiencias al ayudar a editar los dos informes de la OTAN, por lo que estoy muy contento de haber tenido motivos para completar mis reminiscencias personales de ingeniería de software, así que ... hablar. Agradezco a los organizadores de esta conferencia por darme esta oportunidad y, en particular, un medio tardío para publicar el texto que fue tan tristemente censurado del Informe de la Conferencia de 1969.

Referencias

1. JN Buxton y B. Randell, (Ed.). Técnicas de ingeniería de software: Informe sobre una conferencia patrocinada por el Comité de Ciencia de la OTAN, Roma, Italia, 27 al 31 de octubre de 1969, Bruselas, División de Asuntos Científicos, OTAN, abril de 1970, 164 p.

2. P. Naur y B. Randell, (Ed.). Ingeniería de software: Informe de una conferencia patrocinada por el Comité Científico de la OTAN, Garmisch, Alemania, del 7 al 11 de octubre de 1968, Bruselas, División de Asuntos Científicos, OTAN, enero de 1969, 231 p.

3. B. Randell. "Ingeniería de software en 1968", en Proc. del IV Int. Conf. sobre Ingeniería de Software, págs. 1-10, Munich, 1979.

4. M. Shaw. "Recuerdos de un estudiante de posgrado (para el panel," Una retrospectiva de veinte años de las conferencias de ingeniería de software de la OTAN ")," en Proc. 11 ° Int. Conf. sobre Ingeniería de Software, vol. 11, págs. 99-100, 1989. (Reimpreso en Annals of the History of Computing, Anecdotes Department, 11, 2, 1989, págs.141-143).