DSN_XP y las perspectivas

 Enfoque basado en perspectivas

El uso de perspectivas en la aplicación de DSN_XP

DSN_XP entra en contacto con la noción de perspectivas cuando estábamos estudiando el paso desde la ingeniería de software hacia la arquitectura de software. Luego fuimos notando que, por cada nuevo escenario de investigación y por ende por cada actor y patrocinador que colaboraba en ese escenario se podía establecer un conjunto de múltiples perspectivas para lograr mapear el objetivo que investigábamos.

Tres perspectivas en un mismo enfoque 

DSN_XP en el estudio del desarrollo de software en Ecuador, logró identificar que en un posible escenario de uso, tres fuerzas participaban dentro de dicho contexto y que a cada fuerza le correspondía un enfoque específico de uso que lo diferenciaba de los otros dos.

Perspectivas DSN_XP

Bajo el enfoque de perspectivas múltiples, la perspectiva técnica (T) estaría representada por el SoftwareView, mientras que la perspectiva organizacional (O) estaría representada por el BusinessView y finalmente el proceso creativo y de transferencia tecnológica sería cubierto por el TeamView representado la perspectiva personal (P).

El concepto de perspectiva múltiple por Harold A. Linstone

Historia del método

Las raíces del enfoque de perspectiva múltiple tienen dos vertientes: los veinte años de experiencia del autor en la industria aeroespacial, específicamente en la planificación corporativa y el libro de Graham Allison de Harvard, Essence of Decision: Explaining the Cuban Missile Crisis.[1]

El poder y el éxito de la visión "técnica" del mundo y su valor para producir percepciones notables y predicciones excelentes en ciencia e ingeniería siguen siendo incuestionables. Su extensión más allá de sus fronteras es, por tanto, comprensible. 

La economía y las ciencias sociales se han esforzado por adoptar los mismos paradigmas. Las impresionantes herramientas desarrolladas, particularmente desde la Segunda Guerra Mundial, bajo etiquetas tales como investigación de operaciones, análisis de sistemas; Linstone había visto que su análisis y modelado para la toma de decisiones corporativas solo tomaba en cuenta algunos de los factores vitales en el proceso de decisión corporativa y el trabajo de Allison examinaba la crisis de los misiles desde tres puntos de vista diferentes, actor racional, proceso organizacional y política burocrática. Cada uno proporcionó conocimientos que no se pueden obtener con los demás.

A partir de 1977, el desarrollo de este enfoque y aplicación a la gestión de la tecnología condujo eventualmente al libro Multiple Perspectives for Decision Making en 1984.[2] 

En 1999 se publicó una versión actualizada, Toma de decisiones para ejecutivos de tecnología: uso de múltiples perspectivas para mejorar el rendimiento.[3]

Nota: DSN_XP todavía no analiza estos libros referenciados.

Descripción del método

Este método considera tres tipos de perspectivas utilizadas en este enfoque:

Perspectiva Técnica

La ciencia y la tecnología representan la "religión" más exitosa de los tiempos modernos. Desde Galileo hasta el alunizaje tripulado del Apolo, desde Darwin hasta el ADN recombinante, sus métodos han arrojado triunfos deslumbrantes. 

Forman el paradigma de la perspectiva técnica. La visión del mundo T se caracteriza por las siguientes características:

• Los problemas se simplifican mediante la abstracción, la idealización y el aislamiento del mundo real que nos rodea. Existe el supuesto implícito de que los procesos de reducción y simplificación permiten la "solución" de los problemas
• Los datos y los modelos comprenden los componentes básicos de la investigación. Se presuponen igualmente la lógica y la racionalidad, así como la objetividad. Se busca el orden, la estructura y la cuantificación siempre que sea posible. La observación y la construcción de modelos, la experimentación y el análisis suelen estar destinados a mejorar la capacidad predictiva. Se espera la validación de hipótesis y replicabilidad de observaciones y experimentos. Se valora especialmente la consecución de modelos elegantes y soluciones mejores u óptimas.

El enfoque funciona bien para aquellos problemas más allá de la ciencia y la ingeniería que son dóciles o bien estructurados. Algunos ejemplos son la gestión de inventario de fábricas o bancos de sangre, la ubicación óptima del sitio de la estación de bomberos urbana, la programación de líneas aéreas y el precio de los asientos y el análisis económico de entrada y salida. Sin embargo, tropieza con graves problemas cuando se aplica a sistemas sociotécnicos donde los seres humanos, individual y colectivamente, juegan papeles importantes. 

Un ejemplo clásico es la conocida aplicación de Jay Forrester del MIT de su dinámica de sistemas a la corporación (Industrial Dynamics), la ciudad (Urban Dynamics) y el mundo (World Dynamics). Las propias palabras de Forrester reflejan el autoengaño de los ingenieros:

Todos los sistemas que cambian a lo largo del tiempo se pueden representar usando solo niveles y tasas. Los dos tipos de variables son necesarios, pero al mismo tiempo suficientes, para representar cualquier sistema.[4]

El modelo de dinámica mundial usó cinco variables: población, producción industrial, recursos naturales, producción agrícola y contaminación, ¡para construir un modelo de computadora y ejecutarlo hasta el año 2100!

Siendo humanos, los modeladores sucumben al fenómeno Pigmalión. El rey escultor de la mitología griega creó una hermosa estatua de una niña y luego se enamoró de ella. En respuesta a su súplica, la diosa Afrodita le dio vida a la estatua y Pigmalión se casó con su modelo.

Los modeladores de hoy, hipnotizados por la capacidad de las computadoras modernas para dar vida a sus modelos, también se enamoran de sus creaciones. Los modelos se han convertido en realidad para ellos.

Tal vez la manifestación más llamativa de los últimos años sea la seducción generalizada de Wall Street por parte de los “quants”, matemáticos que construyen modelos informáticos sofisticados para administrar el dinero con el fin de obtener el máximo beneficio.

Una forma obvia de evitar tomar un solo modelo demasiado en serio es usar varios modelos en lugar de uno. 

Esto también ayuda a superar las limitaciones siempre presentes en cualquier modelo, como límites artificiales, suposiciones injustificadas y simplificaciones excesivas. 

Los modelos múltiples se usan comúnmente dentro del ámbito de la perspectiva T. En la física clásica, es de gran valor usar modelos de luz tanto de ondas como de partículas, tanto universos newtonianos como einsteinianos para la mecánica. En el desarrollo de aeronaves, el ingeniero de proyectos, el ingeniero aeronáutico, el ingeniero electrónico, el constructor de motores, el diseñador de interiores y el analista de mercado, todos miran la misma aeronave usando distintas perspectivas T. En representación de diferentes disciplinas, utilizan diferentes modelos y datos. Sin embargo, todos operan con los mismos paradigmas T.

Debemos distinguir claramente dos funciones de los modelos (una predicción; la capacidad de hacer predicciones a partir de un modelo matemático, y (b) explicación o comprensión; una ayuda de pensamiento abstracto, que revela o ilumina algún aspecto del comportamiento del sistema de una manera simple o desbloquea una idea.

Las habilidades de la ciencia en el modelado de sistemas se pueden ilustrar de la siguiente manera:

• Excelente explicación y excelente predicción: mecánica celeste
• Excelente explicación y mala predicción: biología evolutiva
• Mala explicación y excelente predicción: mecánica cuántica
• Mala explicación y mala predicción: economía. [5]

En el mundo práctico, con frecuencia nos interesa más un buen pronóstico que una buena explicación.

Pero, como explica Herbert Simon,

El rápido ascenso en la última década de la teoría del caos... ha mostrado las razones fundamentales por las que tal predicción puede ser imposible, ahora y para siempre. Estos están vinculados a la complejidad de muchos sistemas de interés. La naturaleza es capaz de construir, en una escala de microcosmos o macrocosmos o cualquier escala intermedia, sistemas cuya complejidad se encuentra mucho más allá del alcance de nuestras computadoras y supercomputadoras, presentes o futuras. [6]

O, como observa John Casti, la predicción requiere computabilidad y matemáticamente solo es computable un pequeño subconjunto de todas las funciones posibles. Por lo tanto, es plausible que las descripciones matemáticas de muchos fenómenos naturales o humanos sean intrínsecamente incomputables. Cuanto más susceptible es un sistema a la influencia humana, menor es su previsibilidad.[5] 

Perspectiva Organizacional

Los seres humanos son animales sociales supremos. Desde los albores de su existencia, se han organizado en grupos sociales y sociedades. El individuo renuncia a algunos de sus derechos y acepta responsabilidades a cambio de los beneficios que ofrece la pertenencia a un grupo u organización. En su forma más generalizada, tenemos la institución.

En la perspectiva del actor racional de Allison, el analista considera a "Estados Unidos" y "la Unión Soviética" como tomadores de decisiones unitarios, cada uno con objetivos nacionales y alternativas para la acción y deseoso de una elección racional que maximice el valor.

Su perspectiva de proceso organizacional reconoce que un gobierno no es monolítico, sino que está compuesto por organizaciones, cada una con sus propias prioridades y percepciones parroquiales. Por ejemplo, en el caso de la crisis de los misiles en Cuba, al principio fue desconcertante por qué el movimiento de misiles hacia Cuba estaba encubierto en secreto: se utilizaron todos los barcos cubanos madereros y se despejó el puerto cubano donde descargaban, mientras que la preparación y construcción sin camuflar de los sitios de misiles fue fácilmente identificable en las fotografías aéreas obtenidas por los vuelos de vigilancia estadounidenses U-2 sobre Cuba. El misterio se resolvió cuando quedó claro que la responsabilidad de las dos tareas se asignó a diferentes organizaciones soviéticas. La responsabilidad de los arreglos de seguridad de la entrega se le dio a dos agencias que practican el secreto como un procedimiento operativo estándar (SOP): el envío a la GRU, la inteligencia militar soviética y la autorización de seguridad portuaria a la KGB. Sin embargo, la preparación del sitio fue responsabilidad de los equipos de construcción de misiles tierra-aire del Comando de Defensa Aérea Soviética y siguieron sus propios SOP. Los sitios de misiles nunca habían sido camuflados en la Unión Soviética, por lo que no se pensó en cambiar el procedimiento en este caso. [1]

En ingeniería, encontramos que el riesgo tecnológico no puede entenderse puramente en términos técnicos, como el tiempo medio de falla del equipo y el análisis de probabilidad. 

La Comisión Kemeny sobre el accidente nuclear de Three Mile Island reconoció el papel central de los problemas humanos en la operación, gestión y supervisión gubernamental en la anatomía del accidente. El caso del derrame de petróleo de Alaska, discutido a continuación, ofrece evidencia abrumadora de la necesidad de ir más allá de la perspectiva T en la gestión del riesgo tecnológico.

La perspectiva organizacional se enfoca en el proceso más que en el producto, en la acción más que en la resolución de problemas. Las preguntas críticas son "¿hay que hacer algo y, de ser así, qué?" y "¿quién necesita hacerlo y cómo?" en lugar de "¿cuál es la solución óptima?" Debe haber un reconocimiento de que la imposición de soluciones de arriba hacia abajo bien puede fallar si no hay un apoyo "de abajo hacia arriba". En su estudio patrocinado por las Naciones Unidas sobre la degradación ambiental en el Himalaya, Thompson y Warburton concluyen que el enfoque de desarrollo clásico ha sido hacer sonar la alarma y luego decirle al país cuál es la solución, en otras palabras, el enfoque T.

No ha funcionado... porque ha ignorado (como si fuera un simple detalle de implementación) la estructura política, económica y cultural de fondo... Lo que se necesita es un enfoque más sensible, un enfoque que coloque "meros detalles" ––las instituciones que constituyen la estructura profunda––en el mismo centro del escenario... Hay, admitimos, una ruptura considerable entre el enfoque tradicional de problema único/solución única y el que hemos desarrollado aquí. Hay muchas maneras de caracterizar esta ruptura, pero quizás la mejor sea en términos del cambio que hace del pensamiento de producto al pensamiento de proceso. El marco de sistemas ya no es un modelo del problema sino simplemente un mecanismo de evaluación... Necesitamos más de una perspectiva. El abordaje a través de instituciones plurales y percepciones divergentes responde a esta necesidad. [7]

En la perspectiva O tratamos con el poder. No hay una búsqueda intensiva de herramientas analíticas; de hecho, a menudo se desconfía de las "técnicas académicas". Se las considera poco realistas o impredecibles e incontrolables. Puede sorprender al analista orientado a T que el organigrama típico es una guía deficiente con respecto al lugar geométrico de poder en las organizaciones.

El poder real no reside en los documentos y memorandos que describen sus términos de referencia y área de jurisdicción: reside en lo que puede lograr en la práctica el del jefe. El secretario puede ejercer un gran poder, como la amante del rey, sin ninguna autoridad en absoluto o al menos no del tipo que puedes mostrarle a cualquiera. [8]

En organizaciones que operan con tecnologías potencialmente peligrosas, una crisis puede cambiar instantáneamente la estructura de una organización jerárquica a una plana en la que el poder de los niveles anteriormente "bajos" se mejora y se iguala con el de los niveles anteriormente "altos".

El enfoque dialéctico característico de la perspectiva organizacional se refleja en la historia de los pronósticos de recursos energéticos en los Estados Unidos.[9] La profunda división entre los intereses industriales y los conservacionistas de los recursos de petróleo y gas ya era evidente a principios del siglo XX.  En 1908, el Servicio Geológico de EE. UU. (USGS, por sus siglas en inglés) pronosticó recursos petroleros totales de EE. UU. entre 10 y 24,5 mil millones de barriles e indicó que nos quedaríamos sin petróleo entre 1935 y 1943. En 1974, el USGS estimó reservas de petróleo entre 200 y 400 mil millones de barriles. Cada lado aprovechó estas estimaciones para confirmar su postura política. Se han hecho muchos pronósticos desde entonces y, excepto en los períodos de la Primera y Segunda Guerra Mundial, cada facción acusa habitualmente a la otra de manipular los pronósticos para sus propios fines. 

Perspectiva Personal

La perspectiva personal ve el mundo a través de un individuo único. Abarca aspectos que relacionan a los individuos con el sistema y no son captados por las perspectivas técnicas y organizacionales. El individuo puede hacer una diferencia crucial. Un líder efectivo puede imponer su perspectiva sobre la de sus seguidores y la organización, cambiando una corporación o una sociedad. El artista creativo y el líder carismático, el emprendedor y el inconformista están motivados principalmente por su propia perspectiva única.

Desde Pericles hasta Churchill, desde Lincoln hasta Martin Luther King, desde Thomas Watson de IBM hasta Bill Gates de Microsoft, las personas han proporcionado liderazgo. Desde Sócrates y su amor por la sabiduría hasta Rachel Carson y su enfoque en el medio ambiente, las personas han dado ejemplos. 

Las perspectivas de los líderes tienen cualidades únicas: son previsores y tienen una visión del futuro; son capaces de comunicar esa visión de manera efectiva a los demás y así obtener su apoyo; están dispuestos a asumir "apuestas difusas" y riesgos considerables.

Hace doscientos años, Adam Smith observó:

El hombre de sistema... parece imaginar que puede ordenar a los diferentes miembros de una gran sociedad con tanta facilidad como la mano coloca las diferentes piezas sobre el tablero de ajedrez; no considera que las piezas sobre el tablero de ajedrez no tengan otro principio de movimiento que el que la mano imprime sobre ellas; pero que, en el gran tablero de ajedrez de la sociedad humana, cada pieza individual tiene un principio de movimiento propio completamente diferente del que la legislatura podría decidir imprimirle.[10]

Causa y efecto es un paradigma explicativo fundamental de la perspectiva T. Como nos dice el cibernético Heinz von Foerster, es inoperante para explicar el comportamiento de los sistemas sociales. 

La ley que transforma la causa pasada en el efecto presente es cambiada por el mismo efecto que produce. Por lo tanto, no es muy predecible. De hecho, debemos aprender a ver cosas que no podemos explicar. Además, tenemos un punto ciego: no vemos que no vemos.[11]

Un rasgo singularmente personal es la intuición. Al discutir las invenciones en matemáticas, Jacques Hadamard escribe:

Ya es evidente que esas súbitas iluminaciones que pueden llamarse inspiraciones no pueden producirse por la sola casualidad... no cabe duda de la necesaria intervención de algún proceso mental previo desconocido para el inventor, es decir, de uno inconsciente. [12]

Más recientemente, el premio Nobel Herbert Simon y sus asociados exploraron las diferencias entre expertos y novatos en la resolución de problemas de física. Descubrieron que el experto se  guía mentalmente por un gran número de patrones que sirven como índice de partes relevantes del  almacén de conocimientos. Estos patrones son esquemas ricos que pueden guiar la interpretación y solución de un problema y agregar información crucial. Esta capacidad de usar esquemas indexados por patrones es probablemente una gran parte de lo que llamamos intuición física. [13]

Cada individuo tiene un conjunto único de patrones que informan su intuición. Al invocar la perspectiva P, estamos aumentando el proceso T consciente y lógico abriéndonos a los niveles mentales más profundos que almacenan patrones de gran valor potencial. Salk enfatiza específicamente la necesidad de cultivar los reinos intuitivo y de razonamiento, por separado y juntos.

De hecho, la evolución de la mente humana depende de esta relación binaria. [14] Por supuesto, los líderes empresariales siempre han apreciado el valor de la intuición.

Esta es una referencia utilizada por DSN_XP para el fortalecimiento de la versión 0.1 

Método de investigación DSN_XP

DSN_XP y Alistair Cockburn en gratitud constante

 Metodología del software

Metodólogo Alistair Cockburn

DSN_XP entra en contacto con las ideas de Alistair mediante su familia de esquemas estratégicos para equipos de desarrollo de software o CRYSTAL CLEAR

Fuente de conocimientos

Metodología centrada en el potencial humano

Alistair se convierte en una fuente de conocimientos importantes para DSN_XP al poder tener como ejemplo a un investigador del software y metodólogo, todo un estudios de varios artefactos que ha ido estudiando y experimentando en su blog personal. 

Advanced Use Case

Alistair también se vuelve un referente como metodólogo en el uso avanzado de los casos de uso para el diseño de software. DSN_XP venía desarrollando una mirada similar desde nuestro método de modelando avanzado basado en casos de uso y el poder de abstracción que nos brindaba UML.

Manifiesto Agile

Alistair es uno de los mentores del manifiesto agile, de hecho, nuestros registros sobre la concepción del manifiesto y las fotografías que adornan nuestro blog fueron liberadas por el propio Alistair a la comunidad.

IC Agile y el modelado de competencias

Alistair promovió un modelo de certificación que respondía a las necesidades de la comunidad internacional en base a un diseño muy interesante sobre formación de sus estudiantes.

Scrum

Alistair abandona al equipo IC Agile y comienza su gira internacional mediante su capacitación  en Scrum

Corazón de la agilidad

El último esfuerzo metodológico realizado por Alistar se denomina el Corazón de la Agilidad y sintetiza todo el proceso observado a lo largo del tiempo y hasta la fecha, tanto del proceso de capacitaciones como el material pedagógico de entrenamiento.

DSN_XP y el quipu

 Quipu una historia andina

De Guaman Poma De Ayala, Dominio público

DSN_XP crea esta entrada para resaltar algunos aspectos del pensamiento andino que fueron observados cuando estudiamos los fundamentos para elaborar la perspectiva TeamView

Dentro del estudio del proceso de abstracción, habíamos empezado estudiando el pensamiento y su estructura, lo que nos puso de frente ante la perspectiva humana detrás del diseño del software.

Dentro de esta perspectiva, la historia cuenta que siempre existió la necesidad de abstraer partes de la realidad, mediante las cuales fuese posible construir herramientas que ayuden en la velocidad de procesamiento y de cálculo. A este contexto lo denominamos como inteligencia mecánica.

Sobre el Quipu

El quipu (el nombre es derivado del vocablo quechua khipu, que significa nudo, ligadura, atadura, lazada) ​fue un instrumento de almacenamiento de información consistente en cuerdas de lana o de algodón de diversos colores, provistos de nudos, usado por las civilizaciones andinas. [Wikipedia]

Dentro del estudio del pensamiento mecánico y el proceso de abstracción, una variante muy interesante se establece en el estudio sobre los "Quipus" y su utilización como lenguaje de procesamiento y registro de datos.

Estudio de modelos antiguos

Estructura

Poder desarmar un artefacto abstracto se necesita de un proceso de ingeniería inversa, en este contexto, para poder asumir su interpretación, se requieren directrices que permitan sistematizar la información que se desea modelar en primer lugar y luego registrar para su reutilización.

Los expertos referidos en la wikipedia, contemplan la información que cada grupo de nudos es un dígito y se poseen tres tipos principales de nudos:

• Simples, nudo de una vuelta.
• Largos, consistentes en un nudo con una o más vueltas adicionales.
• En forma de 8 

También se utilizan colores para lograr abstraer otro conjunto de conocimientos asociados.

Usabilidad

Se sabe de su uso contable, registro de censos y cosechas. y se investiga sobre su utilidad como sistema de representación lingüística y de memoria de historia, canciones y poemas como también para contar el ganado. Antiguo instrumento inca de registro y de comunicación, que consistía de una larga cuerda, de la cual colgaban 48 cuerdas secundarias y varias otras sujetas a las anteriores. Los nudos que se hacían en las cuerdas representaban las unidades, las decenas y las centenas; y la falta de nudos, el cero.

DSN_XP y la noción de componentes

Sistematización por componentes

Componentización en el análisis del todo

DSN_XP parte desde la escuela estructurada, sin embargo, al investigar el paradigma orientado a objetos descubre los principios de diseño avanzado y en base a esta noción aterriza su conceptualización del proceso de abstracción mediante la noción de componente como unidad de diseño modular a las soluciones propuestas por experimentación.

Historia sobre componentes

Nuestra investigación nos puso en contacto con las ideas de MD. McIlroy y sus ideas sobre componentes software producidos en masa.

Escaneado de P. Naur y B. Randell, 

"Software Engineering, OTAN, Garmisch, Alemania, 7 al 11 de octubre de 1968", 

Componentes de software producidos en masa

MD McILROY 

RESUMEN

Componentes de software (rutinas), para ser ampliamente aplicables a diferentes máquinas y usuarios, deben estar disponibles en familias dispuestas según precisión, robustez, generalidad y desempeño espacio-temporal. 

Fuentes existentes de componentes - fabricantes, casas de software, usuarios grupos y colecciones de algoritmos - carecen de la amplitud de interés o coherencia de propósito para reunir a más de uno o dos miembros de tal familias, sin embargo, la producción de software en general se vería enormemente ayudada por la disponibilidad de espectros de rutinas de alta calidad, así como el diseño mecánico es cómplice de la existencia de familias de componentes estructurales. formas, tornillos o resistencias. 

La charla examinará los tipos de variabilidad necesaria en los componentes de software, formas de producir útiles inventarios, tipos de componentes que están maduros para dicha estandarización y métodos para instituir la producción piloto. 

La industria del software no está industrializada 

Indudablemente, producimos software con técnicas retrógradas. Nosotros sin duda obtenemos el extremo corto del palo en los enfrentamientos con el hardware y su gente porque ellos son los industriales y nosotros los artesanos. 

La producción de software aparece hoy en la escala de la industrialización en algún lugar por debajo de las industrias de la construcción más atrasadas. Creo que es lugar adecuado es considerablemente más alto y me gustaría investigar desde la perspectivas de las técnicas de producción en masa en el software. 

En la frase "técnicas de producción en masa", mi énfasis está en 'técnicas' y no en el plano de la producción en masa. Por supuesto, la producción en masa, en el sentido de replicación ilimitada de un prototipo, es trivial para el software. 

Pero ciertas ideas de la técnica industrial que pretendo son importantes. La idea de los sub ensamblajes se traslada directamente y está bien explotado. La idea de partes intercambiables corresponde aproximadamente a nuestra término 'modularidad' y se respeta esporádicamente. 

La idea de las máquinas herramientas, tiene un análogo en programas ensambladores y compiladores. Sin embargo, este frágil analogía se desmiente cuando buscamos análogos de otros símbolos tangibles de producción en masa. No existen fabricantes de piezas estándar, mucho menos catálogos de piezas estándar. No se pueden pedir piezas a particulares, especificaciones de tamaño, robustez, velocidad, capacidad, precisión o carácter a establecer.

El pináculo del software son los sistemas - sistemas con exclusión de casi todas las demás consideraciones. Componentes, dignos como en el campo del hardware, se desconoce como una rama legítima del software. Cuando nos comprometemos a escribir un compilador, comenzamos diciendo '¿Qué mecanismo de tabla construiremos?' No, '¿Qué mecanismo usaremos?' sino '¿Qué mecanismo construiremos?' 

Afirmo que hemos hecho lo suficiente como para empezar a quitar esas cosas del estante. 

Componentes de software 

Mi tesis es que la industria del software tiene una base débil y que un aspecto de esta debilidad es la ausencia de componentes de software como sub industria  Tenemos suficiente experiencia para percibir el contorno de tal sub industria 

Tengo la intención de elaborar un poco este esquema, pero sospecho que el mismo nombre `componentes de software' probablemente ya haya evocado para usted una idea de cómo podría funcionar la industria. 

También argumentaré que una industria de componentes podría ser inmensamente útil y sugerir por qué no se ha materializado. Por último, plantearé la cuestión de poner en marcha una 'planta piloto' para componentes de software. 

La característica más importante de una industria de componentes de software es que ofrecerá familias de rutinas para cualquier trabajo dado. Ningún usuario de un miembro particular de una familia debe pagar una pena, en generalidad no deseada, por el hecho de que está empleando una rutina modelo estándar. 

Por otra parte, es decir, el comprador de un componente de una familia elegirá uno a medida a sus necesidades exactas. Consultará un catálogo que ofrece rutinas en diversos grados de precisión, robustez, rendimiento espacio-temporal y generalidad. Estará seguro de que cada rutina en la familia es de alta calidad, confiable y eficiente. Esperará que la rutina sea inteligible, sin duda expresado en un lenguaje de nivel superior apropiado para el propósito del componente, aunque no necesariamente compilable instantáneamente en cualquier procesador que tenga para su máquina. 

Él esperará familias de rutinas que se construyan sobre principios racionales para que las familias encajen juntos como bloques de construcción. En resumen, debe ser capaz de considerar con seguridad componentes como cajas negras. 

Así, el constructor de un ensamblador podrá decir `Usaré un Tabla de símbolos A4 de String Associates, en tamaño 500x8' y con ello considere que está hecho. Como beneficio adicional, puede experimentar más tarde con alternativas a este opción, sin incurrir en costos extremos. 

Un ejemplo conocido

Considere la humilde rutina del seno. ¿Cuántas ofertas estándar debe tener el catalogo? De entrada uno piensa en varias dimensiones a lo largo de las cuales desea tener variabilidad: 

• Precisión, para la cual quizás diez funciones de aproximación diferentes podría ser suficiente.
• Cálculo flotante frente a fijo Argumento rangos 0-pi/2, O-2pi, también -pi/2 a pi/2, -pi a pi, -grande a +grande.
• Robustez: desde la validación sin argumentos hasta la señalización de la pérdida completa de significado, a la señalización de especificado violaciones de rango.

Tenemos aquí 10 precisiones, 2 escalas, 5 rangos y 3 robusteces. La última opción de rango y la última opción de robustez son en realidad parámetros arbitrarios especificables por el usuario. Esto nos da un inventario básico de 300 rutinas de seno. Además, uno podría esperar un catálogo completo para incluir una rutina de seno estándar de medición, que entregaría (a un precio) como resultado de cualquier precisión especificada en tiempo de ejecución. 

Otra dimensión de variabilidad, que es quizás difícil de implementar, ya que atiende a necesidades muy detalladas es:

•  Compensación de espacio-tiempo por búsqueda de tabla, ajustable en varias 'sub dimensiones': 
• (a) Tamaño de la mesa 
• (b) Cuantización de entradas (por ejemplo, se sabe que las entradas sean números enteros de grados) Otra posibilidad es 
• (c) Aprovechar las propiedades conocidas de la entrada esperada secuencias, por ejemplo, beneficiándose de la ocurrencia de llamadas sucesivas de seno y coseno del mismo argumento. 

Una empresa que se propone escribir 300 rutinas sinusoidales de una en una y con la esperanza de recuperar el volumen de ventas, sin duda quebraría. no puedo imaginar algunos de los artículos de su catálogo nunca se han pedido. Afortunadamente el costo de ofrecer tal "inventario" no tiene por qué ser casi 300 veces el costo de manteniendo una rutina. 

Existen técnicas automatizadas para generar aproximaciones de diferentes grados de precisión. varias ediciones y las técnicas de vinculación son posibles para insertar o eliminar código pertinente a cada grado de robustez. Quizás solo la dicotomía flotante versus fija en realidad necesitaría rutinas fundamentalmente diferentes. 

Así parece que el inventario básico no sería difícil de crear. El ejemplo de la rutina del seno vuelve a enfatizar un hecho interesante sobre este negocio. Es seguro afirmar que casi todos los senos son computados en punto flotante en estos días, sin embargo, eso no justificaría descartando la opción de punto fijo, porque eso bien podría tirar por la borda un gran parte del negocio en distintas rutinas hechas a medida para miríadas de pequeños control de procesos y otras aplicaciones en tiempo real en todo tipo de diferentes hardware. 

'Producción en masa' de software significa multiplicidad de lo que industria manufacturera llamaría 'modelos' o 'tamaños' en lugar de multiplicidad de repeticiones de cada uno. 

Familias parametrizadas de componentes 

Una frase contiene gran parte del secreto de hacer familias de componentes de software: 'tiempo de vinculación'. Esta es una frase 'de moda' este año, pero es más popular en teoría que en el campo. Casi el único las aplicaciones de múltiples tiempos de enlace que puedo pensar son generadores de clasificación y los llamados tipos de aplicación 'Sysgen': rellenar parámetros en las rutinas de tiempo se compilan para controlar los tamaños de las tablas y, hasta cierto punto, para controlar la elección entre varios cuerpos de código. 

El más conocido de estos, OS/360 Sysgen de IBM es realmente elaborado: las casas de software han establecido ellos mismos como expertos en este trabajo. Sysgen difiere, sin embargo, en un par de formas de lo que tengo en mente como la forma en que una industria de componentes de software podría operar. 

Primero, Sysgen crea sistemas no por construcción, sino por escisión, de un modelo intencionalmente gordo. Los tipos de ajuste en Sysgen son bastante limitados. Por ejemplo, puede asignar cantidades diferentes de espacio para un compilador, pero no puede ajustar el ancho de los campos de enlace de lista en proporción al tamaño del espacio de la lista. Una industria de componentes por otro lado, no produce componentes para su aplicación a un determinado sistema, tendría que ser flexible en más dimensiones, y tendría que proporcionar rutinas cuyos nichos en un sistema estaban menos claramente delineados. 

En segundo lugar, Sysgen no pretende reducir el código objeto o ejecutar tiempo. Por lo general, Sysgen proporciona el preajuste de los valores predeterminados, como si los listados de código de objeto son o no una salida estándar de un compilador. 

Todo el aparato de tiempo de ejecución para interrogar y ejecutar todavía hay opciones, aunque un cliente podría garantizar que nunca lo utilizó si fuera realmente rentable abstenerse. Volviendo a la rutina del seno, esto es algo así como construir una rutina de baja precisión y computar con alta precisión y luego desechar con cuidado los menos bits significativos. 

Habiendo demostrado que Sysgen no es el patrón exacto para un industria de componentes, me apresuro a añadir que en espíritu es casi la única forma en que podría funcionar una industria de componentes exitosa. Para proporcionar un racional espectro de componentes de alta calidad que un fabricante tendría que sistematizar su producción Uno no podría almacenar 300 rutinas sinusoidales a menos que todas fueran en cierto sentido instancias de unos pocos modelos, altamente parametrizados, en los que todos menos algunos parámetros estaban destinados a estar vinculados permanentemente antes de ejecutarse en el  tiempo. 

Uno podría llamar a estos parámetros de límite anticipado parámetros de 'tiempo de venta'. Muchos de los parámetros de un componente de software básico serán cualitativamente diferente de los parámetros de las rutinas que conocemos hoy. 

• Habrá al menos Elección de precisión. Tomado en un sentido generalizado precisión incluye cosas como el ancho de los caracteres y el tamaño de la dirección o el puntero campos. 
• Elección de robustez. La compensación exacta entre confiabilidad y compacidad en el espacio y el tiempo puede afectar fuertemente el rendimiento de un sistema. 
• Este aspecto de la parametrización y el siguiente probablemente clasificarán primero en importancia para los clientes. 
• Elección de Generalidad. El grado en que se dejan los parámetros ajustables en tiempo de ejecución. 
• Elección del comportamiento espacio-temporal. 
• Elección del algoritmo. En las rutinas numéricas, como lo ejemplifica aquellos en el MCCA, esta elección ya está bastante bien atendida. Para rutinas no numéricas, sin embargo, esta elección por lo general se debe decidir en base del folclore. Como algunos algoritmos no numéricos suelen ser espectacularmente inadecuados para un hardware en particular, una amplia variedad es quizás aún más imperativo para ellos. 
• Elección de interfaces. Rutinas que utilizan varios insumos y rinden varias salidas deben venir en una variedad de estilos de interfaz. Por ejemplo, estos diferentes estilos de comunicación de salidas de error deben estar disponibles: 
• Devoluciones alternativas 
• Devolución de código de error 
• Llamar a un controlador de errores 
• Señal (en el sentido de PL/I) 

Otro ejemplo de la variabilidad de la interfaz es que las dimensiones de la matriz para los parámetros deben ser cobrables en formas características de varios de los principales lenguajes de programación. 

• Elección del método de acceso. Diferentes accesos de almacenamiento se deben apoyar las disciplinas, para que un cliente pueda elegir la mejor ajustándose a sus requisitos de velocidad y espacio, las capacidades de direccionamiento de su hardware, o su gusto en el estilo de programación. 
• Elección de estructuras de datos. Ya tocado bajo el tema de interfaces, este delicado asunto requiere una cuidadosa planificación para que los algoritmos sean tan insensibles a los cambios en la estructura de datos como sea posible. Cuando estructuras radicalmente diferentes son útiles para problemas similares (por ejemplo, matriz de incidencia y representaciones de lista para gráficos), varios algoritmos pueden ser requeridos. 
• Áreas de aplicación. Tenemos que empezar a pensar en pequeño. A pesar de los anuncios del efecto de que los compiladores completos están disponibles en una base 'prácticamente lista para usar', no creo que estemos listos para hacer sub ensamblajes de software de eso tamaño en base a la producción. Los componentes más prometedores para empezar son estas: 
• Rutinas de aproximación numérica. Estos se entienden muy bien, y las dimensiones de la variabilidad de estas rutinas también son bastante claras. 
• Ciertos otros procesos numéricos no son tan buenos candidatos; buscadores de raíces y las rutinas de ecuaciones diferenciales, por ejemplo, siguen siendo asuntos para investigación, no producción en masa. 
• Todavía otros procesos 'numéricos', tales como rutinas de inversión de matriz, son simplemente patrones lógicos para secuenciar que están casi desprovistos de variabilidad. Estos pueden ser vendidos por componentes industria en aras de la exhaustividad, pero también pueden tomarse de el MCCA. 
• Conversión de entrada-salida. Las piezas básicas aquí son radix. rutinas de conversión, algunas rutinas de escaneo triviales y crackers de formato. A partir de una colección de familias bien diseñada, debería ser posible fabricar cualquier cosa, desde un simple paquete octal en línea para un pequeño computadora de laboratorio a un paquete de conversión Fortran IV. la variabilidad aquí, especialmente en materia de precisión y robustez es sustancial. Evidentemente, se necesitará una planificación considerable para obtener suficiente flexibilidad sin tener demasiadas rutinas básicamente diferentes. 
• Geometría bidimensional y tridimensional. Las aplicaciones de este tipo van en una clase muy amplia de máquinas y hoy por lo general se mantienen propiedad. Uno puede enumerar fácilmente unas pocas docenas de rutinas fundamentales para geometría. La dimensión pegajosa de la variabilidad aquí está en las estructuras de datos. Según qué aspecto de las figuras geométricas se considera fundamental - puntos, superficies, topología, etc. - se realizarán rutinas muy diferentes requerido. Una línea completa debe atender a diferentes abstractos estructuras y también ser insensible a las estructuras concretas. 
• Procesamiento de texto. Nadie usa los analizadores generales de otra persona o escáneres de hoy, en parte porque una rutina lo suficientemente general para cumplir con cualquier necesidades individuales particulares probablemente tiene tanta generalidad como para ser ineficiente. El principio de tiempos de vinculación variables podría ser muy fructíferamente explotado aquí. Entre el corpus de rutinas en esta área serían generadores de diccionarios y rutinas de búsqueda, escáneres y resultados sintetizadores, todos capaces de trabajar en flujos continuos, en la unidad registros, y varios formatos de listas enlazadas, y bajo modos de acceso adecuados a varios hardware. 
• Administración de almacenamiento. La asignación dinámica de almacenamiento es un tema popular para su publicación, sobre los cuales aún no existe suficiente conocimiento real. Antes construyendo una línea de productos para esta aplicación, uno debería hacer comparación considerable de esquemas conocidos que funcionan en entornos prácticos. Sin embargo, la gestión del almacenamiento es muy importante, especialmente para la manipulación de texto, que debería ser un candidato temprano. 

El mercado 

Viniendo de uno de los usuarios más sofisticados de máquinas, creo tener una amplia oportunidad de ver el trágico desperdicio de la escritura de técnicas de software actual En Bell Telephone Laboratories tenemos alrededor de 100 máquinas de propósito general de una docena de fabricantes. Aunque muchos están dedicados a aplicaciones especiales, una enorme cantidad de software similar debe escribirse para cada uno. Todos necesitan conversión de entrada-salida, a veces solo caracteres alfabéticos individuales y números octales, algunos Fortran completos estilo E/S. Todos necesitan ensambladores y podrían usar macro procesadores, aunque no compilando necesariamente en el mismo hardware. Muchos necesitan números básicos rutinas o generadores de secuencias. La mayoría quiere velocidad a toda costa, unos pocos quieren robustez considerable. 

No hace falta decir que gran parte de esta programación de soporte se realiza sub óptimamente y con una severa sanción científica de desviar a los propietarios de máquinas de sus investigaciones centrales. Para construir estos sistemas de componentes de clase alta tendríamos que rodear cada una de unas 50 máquinas con una camarilla permanente de especialistas en software. Si fuera posible rápidamente y con confianza para aprovechar lo mejor que hay en apoyo algoritmos, un equipo de consultores de software podría guiar a los científicos hacia soluciones rápidas y mejoradas para el apoyo más mundano problemas de sus sistemas personales. 

Al describir la forma en que los laboratorios Bell podrían usar los componentes de software, he intentado describir el mercado en microcosmos. Laboratorios Bell no es el típico de los usuarios de computadoras. como una investigación y establecimiento de desarrollo, por fuerza debe pasar más de su tiempo afilando sus herramientas y usándolas menos que una computadora de producción de tienda. Pero es exactamente ese mercado orientado a los sistemas hacia el cual un la industria de componentes estaría dirigida. 

El mercado estaría formado por especialistas en construcción de sistemas, que serían capaz de usar partes probadas para todas las partes más comunes de sus sistemas. Los mayores clientes de todos serían los fabricantes. (Si no fuera así, sería una señal segura de que los productos ofrecidos no eran suficientemente buenos).  El consumidor final de sistemas basados ​​en componentes debería ver una confiabilidad y un rendimiento considerablemente mejorados, ya que sería ser posible gastar proporcionalmente más esfuerzo en partes críticas de sistemas, y también para evitar las fallas ahora prevalentes de loas más mundanas partes de sistemas, que han sido especificadas por expertos, y luego han sido escritas por hackers. 

Proveedores actuales 

Puede preguntar, bueno, ¿no tenemos exactamente lo que he estado pidiendo ya en varios lugares? ¿Qué pasa con los algoritmos recopilados por el CACM? Qué sobre los grupos de usuarios? ¿Qué pasa con las casas de software? Y que hay con los enormes paquetes de software de los fabricantes? Ninguna de estas fuentes satisface exactamente el propósito que tengo en mente, ni creo que sea probable que ninguno de ellos realmente evolucione a llenar la necesidad. 

Los algoritmos CACM, en un campo limitado, quizás se acerquen más a ser un producto listo para usar generalmente disponible que el de productos comerciales, pero adolecen de fuertes carencias. Primero son una recopilación de contribuciones personales, a menudo estilísticamente variadas. Ellas no encajan en ningún plan, pues el editor sólo puede publicar lo que los autores voluntarios. 

En segundo lugar, al estar efectivamente ligado a un solo lenguaje compilable, logran la arbitrariedad, pero por fuerza deben evitar por completo algoritmos para los que Algol no es adecuado o utilizar circunloquios para abominable que el producto sólo pueda ser considerado como un juguete. 

Tercero, como un adjunto de una sociedad científica, la sección de algoritmos del CACM no puede ocuparse de gran número de variantes del mismo algoritmo. 

La variabilidad sólo puede ser proporcionada por costosos parámetros de tiempo de ejecución. Creo que los grupos de usuarios se pueden descartar sumariamente, y los perdonaré, una arenga sobre sus deficiencias. 

Las casas de software generalmente no tienen los recursos para desarrollar sus propias líneas de productos; su trabajo debe ser financiado, y la gran financiación generalmente solo se puede obtener para productos grandes. Entonces vemos que el software alberga sistemas de suministro, o programas muy grandes, como compiladores Fortran, paquetes de programación lineal o diagramas de flujo. No espero ver ninguna casa de software que anuncia una familia de funciones de Bessel o tabulación de símbolos con rutinas en el futuro predecible. 

Los fabricantes producen cantidades increíbles de software. En general, como este es el material que más se usa, es del todo bastante confiable, un buen gris conservador, que no incluye la mejor rutina para cualquier cosa, pero eso es mejor de lo que el programador promedio es probable que haga. Como escuchamos ayer, los fabricantes tienden a ser bastante pragmáticos en su elección de métodos. Golpean en gran medida razonable equilibrios entre generalidad y especificidad y rara vez utilizan absolutamente enfoques inapropiados en cualquier componente de software individual. Pero el motivo de lucro de donde brotan estas virtudes también engendra su principal cuelgue de los sistemas ahora. 

El sistema es lo primero; los componentes son simplemente incidentes molestos. Fuera de estas cintas de correr no espero ver aparecer componentes de alta clase de utilidad general. 

Una fábrica de componentes 

Habiendo demostrado que es poco probable que nazca entre los tradicionales proveedores de software Paso ahora a la cuestión de cómo un componente la industria podría comenzar. Hay un tamaño crítico que la industria debe alcanzar antes de que sea útil. Nuestro proveedor de 300 rutinas sinusoidales probablemente iría a la quiebra esperando clientes si eso es todo lo que ofreció, solo como un empresa de electrónica que vende módulos de circuito para un solo propósito habría problemas en el mercado. 

Tomará algún tiempo desarrollar un inventario útil, y durante que se necesitará tiempo, dinero y talento. La primera fuente de apoyo que viene a la mente es gubernamental, tal vez canalizado a través de corporaciones de investigación semi-independientes. Parece que el hecho de que el gobierno es el mayor usuario y propietario de las máquinas, debe proporcionar incentivo suficiente para tal empresa que tiene la promesa de hacer una mejora general en el desarrollo de sistemas. 

Incluso antes de fundar una planta piloto, sería prudente tener técnicas demostradas para crear una familia parametrizada de rutinas para un par de propósitos familiares, digamos una rutina sinusoidal y un módulo de E/S de Fortran. Se debe demostrar que estas rutinas se pueden usar como reemplazos en una serie de entornos radicalmente diferentes. Esta demostración podría realizarse por una agencia gubernamental, un contratista de investigación o por un gran usuario, pero ciertamente sin la expectativa de una recompensa inmediata. 

La orientación industrial de una planta piloto debe ser constantemente tomada en cuenta. Creo que todo el proyecto es improbable para la investigación universitaria. Se necesitará talento de calibre de la investigación para hacer el trabajo con economía y confiabilidad satisfactorias, pero el espíritu guía de la  empresa debe estar orientado a la producción. La capacidad de producir miembros de una familia no es suficiente. Distribución, catalogación y planificación racional de la combinación de familias de productos será a la larga más importante para el éxito de la empresa que será el logro puramente técnico. 

El personal de una planta piloto debe parecerse al personal de muchos grandes proyectos de software, con las masas de codificadores eliminados. Serán necesarias una muy buena planificación y una supervisión fuertemente centrada en el producto. Ahí habrá quizás más sabor de investigación incluido de lo que podría estar en un ordinario proyecto de software, porque el nivel de programación aquí será más abstracto: gran parte del trabajo estará en crear generadores de rutinas en lugar de hacer las propias rutinas. 

Las pruebas tendrán que hacerse de varias maneras. Cada miembro de una familia, sin duda, será probado contra algún modelo muy general para asegurar que el enlace de tiempo de venta no cause degradación sobre el enlace de tiempo de ejecución. Probar el producto implicará transliterar las rutinas para que encajen en el hardware. Al monitorear la facilidad con la que las personas relativamente jóvenes hacen prueba del producto, los gerentes podrían estimar la claridad del producto, que es importante para predecir la aceptación del cliente. 

La distribución será un problema delicado. La entrega rápida bien puede ser el estimulante de ventas más valioso de un proveedor de componentes. uno al instante piensa en distribución por enlace de comunicación. Entonces incluso los componentes muy pequeños pueden comercializarse de forma rentable. El catálogo será igualmente importante. Un documento completo y físicamente condensado como el El catálogo de Sears-Roebuck es lo que me gustaría tener para mí si fuera de compras de componentes. 

Una vez que se estableció un corpus de líneas de productos y las ganancias potencial demostrado, esperaría que las casas de software se hicieran cargo del industria. De hecho, si se necesitara apoyo externo durante mucho tiempo, yo diría que la aventura había fracasado (y trato de olvidar que alguna vez me lo había propuesto). 

Tocando los estándares 

No creo que una industria de componentes pueda estandarizarse en existencia. Como es habitual con los estándares, sería precipitado estandarizar antes de que tengamos los modelos. Estándares lingüísticos, siempre que sean flexibles lo suficiente para no impedir modos útiles de cálculo, por supuesto será útil. Muy pronto uno esperaría que una industria de componentes converja en algunos tipos estándar de interfaz. La experiencia sin duda revelará otros estándares para ser útiles, por ejemplo, tamaños de palabras populares y juegos de caracteres, pero de nuevo, a menos que los estándares abarquen la mayor parte de los sistemas de software (como distinguirse de los usuarios), la industria de componentes morirá por falta de mercado. 

Resumen 

Me gustaría ver que los componentes se conviertan en una rama digna de la Ingeniería de software. Me gustaría ver catálogos estándar de rutinas, clasificados por precisión, robustez, desempeño espacio-temporal, límites de tamaño, y el tiempo de enlace de los parámetros. Me gustaría aplicar rutinas en el catálogo a cualquiera de una gran clase de máquinas a menudo muy diferentes, sin demasiado dolor. No insisto en que pueda compilar una rutina particular directamente, pero insisto en que la transliteración sea esencialmente directa. No quiero que la rutina sea intrínsecamente ineficiente debido a que se expresa en términos independientes de la máquina. quiero tener confianza en la calidad de las rutinas. Quiero los diferentes tipos de rutina en el catálogo que son similares en propósito para ser diseñados uniformemente, de modo que dos rutinas similares deben estar disponibles con similar opciones y dos opciones de la misma rutina deben ser intercambiables en situaciones indiferentes a esa opción. 

Lo que acabo de pedir es simplemente industrialismo, con términos de programación sustituidos por algunos de los términos más orientados mecánicamente apropiados para la producción en masa. Creo que hay áreas considerables de software listo, si no atrasado, para este enfoque.

DISCUSIÓN 

Ross: Lo que ha estado hablando Mcllroy son cosas que hemos estado jugando con por ejemplo, en el sistema DEA tenemos los llamados característica-característica. Esto nos permite sortear el problema de los cargadores. Nosotros siempre podemos incrustar nuestro sistema en cualquier sistema de carga disponible, el problema de la vinculación está muy entrelazado allí, por lo que estamos a merced del medio ambiente. Un ejemplo es un sistema generalizado de notificación de alarmas en que puede informar cosas sobre la marcha o sacar todo tipo de información dinámica. El mismo sistema da 14 versiones diferentes del manejo de alarmas. Me parece que la macro-expansión es el punto de partida para algunos de los problemas técnicos que hay que resolver para poner estos ideas muy importantes en la práctica. 

McIlroy: Parece que ha automatizado algunos tipos de variabilidad que yo pensaba eran más especulativos. 

Opler: El sistema TOOL producido hace seis años para Honeywell fue complementaria a la descrita por McIlroy. Tiene facilidades para poner cosas juntas, pero no proporcionó los componentes. La dificultad fue que produjimos componentes rudimentarios para ver cómo funcionaría el trabajo del sistema, pero las personas para quienes desarrollamos el sistema no entendían que iban a proporcionar sus propios componentes, por lo que simplemente se quejaron que el sistema no era bueno. Pero estoy muy entusiasmado con lo que usted sugiere. 

Perlis: El sistema GP de la primera Univac era un sistema para desarrollar software personalizado mientras permanezca en esa máquina. Los autores de este sistema me preguntó: ¿Cómo se generalizaría esto a otras computadoras? No sabían cómo hacerlo en ese momento, y supongo que no ha sido hecho. Tengo una pregunta para Mcllroy. No te escuché mencionar qué me es la más obvia de las parametrizaciones, a saber, construir sistemas de manejo de archivos de datos comerciales. Entiendo que Informática tiene uno fuera de lo cual todo el mundo dice que está bien, pero -. Esto parece ser una típica actitud hacia los sistemas parametrizados. 

McIlroy: Mi razón para dejar eso fuera es que esta es que no se sobre ello. 

Perlis: Probablemente sería una de las áreas más fáciles, y una con la mayoría de los clientes Antes de que d'Agapeyeff hable, tengo otro comentario. [Risas]. Los especialistas en cada parte del software tienen una curiosa visión de el mundo: Todas las partes del software excepto la suya son simples y fáciles parametrizado; la suya es totalmente variable. 

d'Agapeyeff: No hay paquete que haya recibido más atención por parte de los fabricantes que el manejo de archivos. Sin embargo, apenas existe un sistema importante, sé que eso se basa únicamente en el sistema estándar producido por el fabricante. Es extremadamente difícil construir este software en un manera que sea eficiente, confiable y conveniente para todos los sistemas y donde la naturaleza del paquete no se impone al usuario. La razón es que no puedes atomizarlo. Cuando el trabajo ha tenido éxito, tiende a preocuparse por los paquetes que tienen alguna estructura. Cuando llegas a pequeñas unidades no es económico hacerlos aplicables a un gran conjunto de usuarios, usando diferentes máquinas con diferentes idiomas, y hacer todo el trabajo de encuadernación, de modo que no se tarde el doble en descubrir cómo cárgalo. Los problemas con Sysgen no se pueden prescindir, son inherentes. Pero, ¿por qué necesitamos sacar átomos del estante? Lo que tu quieres es una descripción que se puede entender, porque el tiempo necesario para codificarlo en su propio sistema es realmente muy pequeño. De esa manera puedes insertar tus propios matices. El primer paso en tu dirección debería ser mejor descripciones 

Endres: Dos notas de precaución: descartaste los algoritmos en el Comm. ACM en parte porque están escritos en lenguaje de alto nivel, así que entiende que te refieres a rutinas escritas en un lenguaje más orientado a lenguaje de máquina. Creo que simplifica demasiado el problema de la transliteración o asumes un estándar de máquina de facto? Segunda pregunta: Usted se refiere a la problemática de Sysgen, donde recortas piezas de una gran colección. Si en cambio, quieres armar sistemas, creo que los problemas de Sysgen pueden convertirse en una dimensión más grande. ¿Quién asumirá este costo y mantendrá el ¿sistema? 

McIlroy: Los algoritmos en el Comm. ACM usa efectivamente un lenguaje, que es adecuado para una clase particular de aplicaciones. esto puede no ser el correcto para cosas como paquetes de entrada/salida. En la segunda pregunta: Estoy convencido, con usted, de que al principio será más difícil construir sistemas por acreción, en lugar de por escisión. Las personas que construyen los componentes tendrán que ser constructores de sistemas calificados, no comunes y corrientes usuarios.

Kjeldaas: Estoy totalmente a favor de esta idea. Creo que los ejemplos mencionados son dentro del estado del arte. Sin embargo, más adelante querremos macros que necesiten parámetros que tienen relaciones más intrincadas, por ejemplo, si desea algunos relación funcional entre los parámetros. Necesitaremos algo de lenguaje para describir los parámetros. Otro punto: la documentación también puede ser incluido en este. Cuando le hayas dado los parámetros al programa, puede dar los mismos parámetros a la documentación, y la documentación para el uso particular se puede producir automáticamente alimentación para diferentes máquinas que plantearán grandes problemas, que necesitan investigación. 

Kolence: ¿Puedo enfatizar un punto: Mcllroy afirmó que el la industrialización tiene que ver con el diseño, no con la replicación proceso. Estamos interesados ​​en un problema de diseño en masa. al hablar de la implementación de componentes de software, todo el concepto de cómo uno se ignora el software de diseños. Sin embargo, esto es algo clave. 

Naur: Lo que me gusta de esto es el énfasis en los principios básicos de construcción, y en el hecho de que los grandes sistemas están hechos de componentes más pequeños. Este tiene una fuerte influencia en la educación. Lo que queremos en la educación, particularmente en el nivel más elemental, es empezar a adoctrinar el conocimiento de los componentes de nuestros sistemas. Una comparación con nuestros colegas de hardware es relevante. ¿Por qué tienen mucho más éxito que nosotros? Yo creo que una fuerte razón es que hay un campo bien establecido de ingeniería electrónica, que los jóvenes empiecen a aprender sobre la tecnología de la Ley de Ohm a la edad de catorce años o por ahí, y que las resistencias y similares son componentes conocidos con características que han sido expuestas en duración en el primer nivel de educación. Los principios componentes de nuestro Los sistemas deben clasificarse de tal forma que puedan ponerse en educación elemental. 

Gill: Dos puntos: primero sobre la cuestión del catálogo. espero que podamos hacer mejor que el catálogo de Sears-Roebuck. Seguramente lo que queremos es un catálogo conversacional computarizado. Segundo punto: ¿qué es lo que Ud. realmente vendes cuando vendes una pieza de software, ¿qué hace exactamente un ¿Se parece el contrato de software? 

Barton: La charla de Mcllroy estuvo tan bien hecha que me tomó cerca de tres minutos para darse cuenta de lo que está mal con esta idea. Otro cumplido: si yo estuviera ejecutando Intergalactic Software, contrataría a Mcllroy como gerente. Ahora el punto serio: Durante los últimos años he enseñado el ACM Curso 'Estructuras de información' y usó el juego para no dejar que nadie codificara o escribir cualquier cosa en cualquier lenguaje de programación en absoluto. acabamos de pensar sobre representaciones de datos. Si de esta manera logras que la gente se deshaga de la costumbre de escribir código de inmediato, de pensar procedimentalmente, luego algunos muy diferentes puntos de vista sobre las representaciones de la información vienen a la vista. En McIlroy´s hablar de componentes estándar que tienen que ver con estructuras de datos tengo la sintiendo que esto no es un problema para sacar de las universidades todavía. Ahora una visión herética: no creo que hayamos suavizado las cosas lo suficiente en máquinas todavía. No creo que lleguemos a ninguna parte tratando de cuantificar el compensación de espacio-tiempo a menos que descartemos tamaños de palabra fijos, caracteres fijos tamaños, representaciones numéricas fijas, todo junto en máquinas. Sin que estos, lo propuesto por Mcllroy demostrará ser no del todo práctico. 

Fraser: Deseo discrepar con d'Agapeyeff. creo que será posible parametrizar la representación de datos y la gestión de archivos. A partir de una experiencia particular del sistema de archivos aprendí dos lecciones: primero, hay una gran cantidad de parámetros, para ser seleccionados de forma no excluyente manera. La selección de los parámetros es tan complicada que es apropiado poner un compilador en la parte delantera de la distribución de software mecanismo. Quizás estemos hablando más de compiladores de lo que creemos. En cuanto a los catálogos: en Inglaterra, un catálogo de materiales de construcción es un catálogo muy ad hoc, tienes bridas a la izquierda para ir con la mano izquierda puertas, etc. Creo que es probable que el catálogo sea ad hoc en esa naturaleza, en lugar de como un catálogo de electrónica donde los componentes son más intercambiable. El segundo problema es la cuestión de escribir este compilador. Nuestro generador de gestión de archivos efectivamente generaría una gran cantidad de diferentes sistemas de gestión de archivos, muy por encima de los 500 que mencionó Mcllroy. No había duda de probar todos estos. Nosotros produjo una solución ad hoc a este problema, pero hasta que se realicen más investigaciones hecho sobre este problema, no creo que la sugerencia de McIlroy sea realista. 

Graham: Hablaré de un adjunto a esta idea. En Multics usamos un subconjunto de PL/I, aunque PL/I es bastante inadecuado, en que el primitivo Las operaciones del lenguaje no son realmente adecuadas para el diseño del sistema. En Multics realiza una gran cantidad de administración de directorios, operaciones simples como agregar y borrar entradas, pero en un directorio complicado. Con un nivel superior lenguaje con estas operaciones como primitivas uno podría fácilmente escribir un nuevo sistema. Al simular las primitivas, se podría probar el desempeño del sistema antes de construirlo realmente. Si uno tuviera el catálogo de Mcllroy almacenado en el sistema, con los tiempos de muchas rutinas, luego la simulación hacer una copia de seguridad de este lenguaje de nivel superior podría, de hecho, referirse al catálogo y use los tiempos reales para una nueva máquina que esta compañía ofreció y obtener tiempos realistas. Otro punto, deseo refutar la sugerencia de McIlroy que esto no es para universidades; Creo que es. hay muy dificiles problemas en esta área, como la parametrización de rutinas más sofisticadas, en particular los del área del compilador. Estos son aptos para las universidades. 

Bemer: Estoy de acuerdo en que el método del catálogo no es adecuado. nosotros no tener los descriptores para ir a buscar. No hay nada tan mal descrito. como formatos de datos, no hay estándares y no hay señales de que estén siendo desarrollado. Antes de que tengamos estos, no tendremos los componentes. 

McIlroy: Es por esa razón que ahora sugiero el tipo Sears-Roebuck. La búsqueda en línea puede no ser la respuesta correcta todavía.

DSN_XP y los escenarios

 Metodología de escenarios

Escenario es el espacio/tiempo donde se presenta la acción

DSN_XP llega a reconocer como artefacto al concepto de escenario cuando comenzamos a profundizar en el modelado avanzado de casos de uso.

Este es un texto que tomamos de referencia del estudio de Alexandra C. Cely

Revista Ingeniería e Investigación Nº. 44 Diciembre 1999

Modelado Avanzado

Existen diferentes formas de aproximarse al futuro, siendo la prospectiva la única que lo aborda como una realidad múltiple e indeterminada, obtenida como resultado de las infinitas posibilidades de acción humana, reflejada en los diferentes proyectos (acciones concretas), anhelos y temores de los grupos sociales. Para desarrollar estudios de prospectiva existen diferentes metodologías entre las que se encuentra la de escenarios, cuyo uso se ha venido generalizando durante los últimos diez años gracias a la claridad en la presentación de los resultados y a la articulación de los mismos con la intencionalidad de la acción humana.

Nociones de tiempo futuro

DSN_XP resalta un patrón de comportamiento en las investigaciones realizadas sobre los factores que apoyan al proceso creativo de modelar y diseñar software como solución tecnológica, el patrón está relacionado con la noción del tiempo y de forma especial con la necesidad de proyectarse a futuro para conocimiento prospectivo.

Desde el principio de la civilización, la especie humana ha intentado acercarse al futuro de diferentes maneras utilizando la magia, las artes adivinatorias, los oráculos y finalmente la proyección matemática y la extrapolación de tendencias. Al avanzar el tiempo, la concepción y del futuro cambia como reflejo de los cambios realizados en la humanidad, así se ha conceptuado este espacio-tiempo ya no solo como una realidad única, sino que, se la considera actualmente como múltiple e indeterminado.

La nueva "manera de abordar el futuro" surgida de este cambio de mentalidad, es la prospectiva, cuya premisa principal se basa en que el futuro no sucede ciegamente, sino que depende de la acción del hombre. Por esta razón, la prospectiva se convierte en una herramienta fundamental de planeación, que además de dilucidar el futuro, permite orientar las acciones humanas que conducirán a la realización del mismo.

La metodología de escenarios se diseñó inicialmente utilizando los conceptos del análisis de sistemas, nacido en los Estado Unidos durante los años cincuenta y sesenta, posteriormente, dicha metodología demostró ser la mejor forma de expresar los resultados de un ejercicio prospectivo.

Un modelo de escenarios posee tres aspectos fundamentales:

1. Analizar el fenómeno en estudio, desde un punto de vista retrospectivo y actual.
2. Analizar la influencia de los grupos sociales que son gestores del desarrollo del fenómeno así como de los factores de cambio.
3. Presentar los resultados finales en forma de escenarios.

Definiciones

• Escenario: constituye la descripción de un futuro posible y de la forma de alcanzarlo.
• Escenarios Posibles: son todos aquellos escenarios que se puedan imaginar sin importar si su probabilidad de ocurrencia es alta o baja .
• Escenarios Realizables: son los escenarios cuya ocurrencia es factible, teniendo en cuenta todas las restricciones del sistema.
• Escenarios Deseables: son los escenarios a los que los actores desean llegar, también pueden ser calificados como los escenarios más convenientes. Forman parte de los escenarios posibles y no necesariamente son realizables.
• Sistema: el sistema es el conjunto de elementos cuya interacción genera nuevas cualidades que no poseen sus componentes a nivel individual y, por tanto, se debe estudiar como un todo. De esta forma, las partes son explicadas en términos del todo. Dentro de la metodología prospectiva, el sistema está constituido por el fenómeno, área o tema en estudio y su entorno explicativo; éste involucra factores políticos, demográficos, políticos, económicos, industriales, sociales, tecnológicos, etc.
• Actores: son todas las personas que pueden influir significativamente sobre el sistema mediante la toma de decisiones o la realización de proyectos. Son los gestores del desarrollo y pueden pertenecer a cuatro grandes grupos:
• El poder: organismos del estado
• La producción: sector industrial
• El saber: entidades que generan conocimiento, universidades, etc.
• La comunidad: beneficiarios de los productos o servicios.
• Variables: también denominados factores de cambio, son fenómenos que orientan la evolución o mutación del sistema en estudio. Pueden ser de orden económico, social, político, cultural, administrativo, científico, tecnológico, ambiental, jurídico, etc. Estos factores de cambio se perciben como proyectos, tendencias, gérmenes de cambio, temores y problemas de cada uno de los actores.
• Anhelo: es la Intención que tiene un actor de hacer algo que solucione un problema concreto en un sector determinado.
• Invariante: fenómeno que se supone permanente, más no constante en cuanto a sus características y/o magnitud, hasta el horizonte de tiempo estudiado.
• Gérmenes de futuro: factores de cambio escasamente perceptibles hoy, pero que constituirán las tendencias dominantes del mañana; también se denominan hechos portadores de futuro.
• Conflicto: es una relación que se establece entre dos o más actores que presenten posiciones antagónicas frente a una misma variable. Esta disfunción también se denomina ruptura de tendencias.
• Alianza: es una relación que se establece entre dos o más actores que presenten posiciones coincidentes respecto a una variable del sistema.
• Evento: es una solución concreta a un problema determinado, cuya única característica radica en su ocurrencia o no.
• Experto: son aquellas personas que conocen a profundidad el sistema en estudio o parte de él y que generalmente pertenecen a alguno de los actores.

Fases y objetivos del método

La metodología de escenarios posee tres objetivos fundamentales, los cuales deben desarrollarse a cabalidad; dichos objetivos son:

• Descubrir y vincular las variables claves que caracterizan al sistema en estudio mediante un análisis explicativo global.
• Determinar a partir de las variables clave, los actores fundamentales y los medios de que disponen para concretar sus proyectos.
• Describir, en forma de escenarios, la posible evolución del sistema en estudio a partir de la observación y análisis de las variables claves y de los comportamientos de los actores, respecto a un juego de hipótesis.

Para lograr estos objetivos, la metodología de escenarios se desarrolla en dos fases principales: la construcción de la base analítica y la elaboración de los escenarios.

Construcción de la base analítica

En esta primera fase se pretende realizar una imagen de la situación actual del sistema y su entorno.  Incluye la delimitación del sistema, el análisis de influencia y subordinación de las variables claves o fundamentales y la descripción actual del sistema.

Inicialmente se elabora una lista completa de las variables que influyen sobre el sistema y que deben ser atendidas sin importar si pueden ser cuantificables o no. El propósito es obtener una visión global del sistema y su entorno consiguiéndose así, una definición bastante precisa del mismo.

• Listado de variables (entrevistas, expertos, etc.)
• Análisis de dependencia, influencia, relación entre las variables y su jerarquización de acuerdo a niveles de impacto y profundidad.
• Análisis estructural
• Análisis de situación actual y los gérmenes de cambio y estrategia de actores.
• Construcción de un cuadro de estrategias de los actores, síntesis del análisis de situación actual, retos a futuro.

Nota: se deben tomar en cuenta datos cualitativos como factores económicos, sociológicos, políticos, ecológicos, etc. Deberá considerarse el uso del método de análisis del juego de actores.

Elaboración de escenarios

Una vez obtenidos los resultados de las fases anteriores se procede a la elaboración de hipótesis y la obtención de los escenarios, tal como la figura.

Esto se logra mediante la formulación de hipótesis, las cuales dirigen los escenarios.  Estos escenarios deben estar dimensionados en términos de sus componentes esenciales y pueden ser de tipo demográfico, técnicos, social, político, económico, etc.

Dado que algunos elementos del sistema, tales como el resultado de los posibles conflictos entre actores, son inciertos en el futuro del mismo; se deben formular hipótesis sobre la evolución de tendencias y sobre dichos elementos inciertos.  De esta forma, a cada juego de hipótesis le corresponderá un escenario que se puede construir y cuya realización es más o menos probable.

DSN_XP y la experimentación

 La experimentación en DSN_XP

Experimentación base

Un principio del método que dirige el proceso de diseño para DSN_XP radica en la experimentación con el modelo que fue diseñado para poder abstraer un contexto de usabilidad.

Experimentación

Nuestro contexto de experimentación, está íntimamente relacionado con el proceso de codificación y la racionalización mediante la algoritmia, para efectos de lograr crear una solución como sistema, utilizando los principios de cálculo y de modelado que el lenguaje de programación lo permita.

Fue la experimentación la única forma que encontramos para lograr desarrollar nuestras habilidades de programación, ya que no todos teníamos acceso al hardware necesario para un aprendizaje continuo.  

Debido a que, los programas que codificábamos eran sencillos en base a nuestra limitada comprensión de la semántica que se sujetaba al lenguaje de programación escogido para el efecto.

Parte del proceso de aprendizaje radica en la observación del código realizado por una fuente de conocimiento que estudiamos (tutor o libros o videos u observaciones al proceso de codificar de un tercero), por ello, es nativo para DSN_XP el pensamiento inverso o la capacidad de leer código de terceros para efectos de establecer un modelo de solución a problemas específicos por experimentación.

Prototipar

DSN_XP entiende por prototipar justamente al concepto que deseamos expresar como experimentación, ya que parte de la comprensión del lenguaje de programación radicaba justamente en trabajar con las ventajas que determinan la usabilidad de un lenguaje de programación, esto es programar una abstracción y la capacidad del dominio de la sintaxis del lenguaje de programación.

Ahora bien, el prototipado para nosotros podía tener varios contextos de uso y uno de ellos era justamente el utilizar el lenguaje de programación para generar una secuencia de eventos y así lograr un comportamiento por parte del sistema programado.

DSN_XP y el PETI

 El proceso de planificación

Componentes del Plan y su estrategia

Este es solo un referente del proceso de planificación que puede desarrollarse para lograr armar un PETI o Plan Estratégico de los Sistemas de Información (SI) dentro de las Tecnologías de Información (TI).

Componentes de planificación

¿Cuáles son los componentes básicos de un plan estratégico? Aunque el plan estratégico de los sistemas de información SI difiere de un plan de negocios en muchos aspectos, existen varios conceptos a tener en cuenta:

• Identificación de dónde se encuentra hoy: evalúe el entorno para responder la pregunta, ¿Dónde estamos ahora?, en un plan estratégico de SI, esto incluye el mirar interna y externamente desde la perspectiva tanto del negocio como de los SI. Una vista externa responderá a la preguntas ¿Qué es posible?, y ¿Cuáles son las mejores prácticas? Debido a que la empresa debe impulsar SI, debe entonces comprender a fondo los objetivos y desafíos comerciales, además de donde se encuentran los sistemas de información actualmente.
• Identificación de dónde quiere estar en el futuro: a través del proceso de planificación, se puede desarrollar la visión y la estrategia para responder a la pregunta ¿Dónde queremos estar? En un plan estratégico de SI, responda la pregunta desde una perspectiva empresarial y de los SI.  La dirección a futuro debe ser el principal determinante en el establecimiento de la dirección  de los SI.

La CEPAL en su documento titulado “Planificación estratégica e indicadores de desempeño en el sector público”, define la Planeación Estratégica, PE, como “una herramienta de gestión que permite apoyar la toma de decisiones de las organizaciones en torno al quehacer actual y al camino que deben recorrer en el futuro para adecuarse a los cambios y a las demandas que les impone el entorno y lograr la mayor eficiencia, eficacia y calidad en los bienes y servicios que se proveen. 

Desde el punto de vista metodológico, la planificación estratégica consiste en un ejercicio de formulación y establecimiento de objetivos de carácter prioritario, cuya característica principal es el establecimiento de los cursos de acción (estrategia) para alcanzar dichos objetivos. Desde esta perspectiva la PE es una herramienta clave para la toma de decisiones de las instituciones públicas